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(57) A communication system is presented whereby 
sequences of video screens sent from a host CPU to a 
video controller can be stored and subsequently re- 
trieved by a terminal located remote from the host CPU. 
The host CPU and video controller form part of a server 
arranged within a distributed computing system. An ad- 
ministrator situated at the remote terminal can retrieve 
select video screens produced during server operations 
to determine information regarding the server configu- 
ration and possible causes of server failure or future fail- 
ure. The sequence of video screens thereby represent 
video screen changes stored upon a server controller 
adapted for coupling to the server expansion bus. The 
video screen changes represent a sequence of video 
screen changes occurring prior to server failure or after 
server reset. Those changes provide beneficial informa- 
tion to an administrator located remote from the server, 
and allows the administrator to communicate with the 
server using several possible communication protocols. 
The server controller snoops display data written from 
the host CPU to the video controller and mirrors the dis- 
play data upon buffers within the server controller. Infor- 
mation within the buffers can be called upon by a re- 
motely situated administrator regardless of whether 
server power is lost in the interim. 
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Description 

This invention relates to a distributed computing system, and more particularly to a host computer ("host") which 
can be accessed from a terminal not physically connected to the host and located at a site remote from the host. The 

5 remote terminal can access a stored sequence of video screens, such as a sequence of video screens occurring during 
host reset or failure operations. The sequence of video screens can then be replayed by a computer administrator 
located at the remote terminal. Remote access to those video screens allows the administrator to determine how a 
host operating system is responding to a reset, or possible reasons why the host system failed. Provided with the host 
is a printed circuit board ("PCB") which can be inserted into a backplane which accommodates the host. The PCB 

io comprises a processor and memory for storing the sequence of video screens even when power is lost to the host. 

Distributed computing systems are generally well known. Such systems allow communications between application 
programs hosted on numerous computer workstations. There are numerous types of distributed computing systems, 
often classified by the geographical extent of their communication capability. Terms used to classify the geographical 
breadth of distributed computing systems are. for example: local area networks (LANs), metropolitan area networks 

'5 (MANs) ; and wide area networks (WANs). 

Many of the more popular distributed computer systems employ a file server ("server"). Files, or data, are managed 
by a host within the server. Servers are particularly beneficial in allowing workstations fast access to files stored by the 
server. Accordingly, file servers embody a host computer which responds to an operating system program (a popular 
operating system being, e.g., Windows NT®) to not only orchestrate the files, but also to maintain file security, file 

20 backup, etc. 

An important aspect of maintaining host functions within a server is to manage the host from a site remote from 
the host and, more specifically, to manage the host at a site remote from the workstations physically linked to the server. 
Recent trends have seen a steady increase in the number of servers used in business. Nowadays, servers are liberally 
used possibly at each location of a business entity - rather than employing a centralized mainframe at one location. 
25 Unfortunately, funds available to administer many server hosts located at disparate locations is decreasing. While data 
placed on these servers is considered critical to the business, there remains insufficient means for ensuring their proper 
operation from a single service site. An expectation that an administrator travel to remote server sites to fix a problem 
is not only impractical but quite costly given the expense associated with server downtime. 

Many operating systems, or applications associated with those operating systems, allow access to the host from 
30 a remote site often called a "virtual terminal". A virtual terminal, while not physically connected to the host, nonetheless 
allows remote control of certain operations of the host. Products such as COMPAQ Server Manager/R® ("SMR") and 
COMPAQ Insight Manager® ("CIM") ; obtainable from Compaq Computer Corp., have attempted to address some of 
the issues involved in managing a network of distributed servers from a single, remote site. These products allow, inter 
alia, an administrator to be alerted as to a remote server failure, to reset the server from the remote site, and to access 
35 certain information provided on the server console. 

It is certainly beneficial to allow remote control of certain server functions, especially those needed to reset one 
or more servers within a network of servers. Any downtime caused by server failure is probably the most costly time 
involved in running a distributed computer system. The causes of server failure, often termed server host "crash" are 
numerous. Any number of malfunctions or design flaws associated with the server hardware, server operating system 
•to or application programs running on the server may account for a server crash. If a server crashes, then file access is 
often lost and business records are temporarily inaccessible until the cause of failure is fixed. 

A true benefit would result if an administrator located remote from the server can do more than be alerted to, and 
then reset, a failed server. In particular, it would be advantageous for the administrator to determine the cause of server 
failure so that he/she can possibly prevent future failures before they occur. Prevention of failure is as important, if not 
•*5 more important, than resetting a server that has crashed. 

The cause of a failure is generally displayed on the server console at the time in which the server crashes. Moreover, 
irregularities in the server host hardware or operating system software can be detected upon reset (or "boot"). Those 
irregularities can lead to future failure if not attended to by the administrator. Accordingly, it would be beneficial to gain 
access to what is displayed on the server host console not only during server reset (or failure) but also leading up to 
so server reset/failure. Information within the video screens (more particularly the sequence of video screens) displayed 
on the server console, which occur during server failure or reset would help remotely located administrators determine 
(and hopefully fix) an existing server failure or potential failure. 

The video screens, resulting from a reset or failure of the server, comprise a sequence of video screen changes 
displayed on the host server console by the operating system, system basic input output system ("BIOS"), server 
55 application program or other system software. In particular, capture of two screen change sequences are of particular 
interest to a server administrator. In order to fix an existing failure or a future failure, it would be beneficial that the 
administrator be given the sequence of screen changes prior to server failure as well as the sequence of screen changes 
following a reset. Examples of server failure screens displayed on the server console are Microsoft Corp., Windows 
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NT® "blue screens" and Novell Corp.. NETWARE® ABEND message which appear on the server console when the 
respective operating system crashes. These screens provide information such as processor fault indicia, system soft- 
ware routine addresses, and pertinent system memory contents. Upon reset of the server, the power on self test 
("POST") code, associated with the aforementioned operating systems, typically performs some system diagnostics 
and displays information regarding failures detected to the server console screen. Hence, a means for capturing such 
sequences and replaying them at a remote management site is desired. 

In addition to hardware and software problems, a server can also fail if power to the server is halted. Unfortunately, 
if power is halted, any screen changes as to what occurred prior to failure will be lost. A server is therefore needed 
which employs a mechanism for saving reset and failure screen changes even when power to the server is lost. The 
stored screen changes may then be beneficially read at a future date by a remotely situated administrator. The desired 
mechanism is one which can therefore maintain screen information during power loss, and can selectively forward 
power only to critical units within the mechanism. Accordingly, a mechanism is needed which is preferably embodied 
upon a PCB mountable within a server chassis. The PCB is desirably connected to the server host and includes media 
for storing screen information output from the host, and for maintaining that information even when server power is 
discontinued. 

Communication between a remote site and a server is typically performed via text-based connection protocols, 
generally known in the industry as American National Standards Institute ("ANSI") terminal emulation protocols. Al- 
though terminal emulation protocols provide a certain level of functionality, it is desirable that other protocols, in par- 
ticular protocols which enable application layer protocols such as simple network management protocol ("SNMP"), a 
protocol for communication of server management information, be supported on a point-to-point ("PPP") communica- 
tions link between the server and the remote site. If a server is to include a PCB embodying a system for communicating 
with the remote site using a plurality of communications protocols, then it is desirable that subsystems upon the PCB 
determine which of the supported protocols (i.e., text-based, PPP, etc.) the remote site is using as it communicates 
with the server. 

The problems outlined above are in large part solved by a remote communication system of the present invention. 
The remote communication system employs a server controller which can be connected to an expansion bus upon the 
server. Preferably, the server controller is embodied upon a PCB having edge connectors connectable to an EISA 
expansion bus. The server controller comprises detection logic which detects write cycles within a video address range. 
The write cycles are initiated as display data forwarded to a video controller also arranged upon the expansion bus. 
Detection logic thereby snoops the expansion bus for display data, and then mirrors the display data to a controller 
memory. 

The controller memory, like the detection logic, is embodied upon the server controller PCB and includes a plurality 
of buffers. Display data forwarded to the controller memory is captured in a local frame buffer which stores frame-by- 
frame the display data. A previous frame or screen of display data is compared with a current frame or screen of display 
data to indicate a possible change. The change, as registered on the server display, is stored within current sequence 
buffers also associated with the controller memory. The current sequence buffers store three types of changes: a 
sequence of video screen changes which occur prior to server failure or reset, a sequence of video screen changes 
which occur after the most current server reset, and a sequence of video screen changes which occur after a reset 
which occurs prior to the most recent reset. Storing current and previous reset video screen changes as well as failure 
video screen changes (i.e., blue screens or ABEND messages) allows an administrator to determine reasons for server 
failure or possibilities of future failures. 

A terminal located remote from the server can be used by an administrator to draw upon any of the various se- 
quences of video screen changes stored within the controller memory. The server controller can recognize different 
types of communication protocols sent from the remote terminal. A local processor within the server controller can 
recognize the communication protocol being sent by employing state machines dedicated to each protocol. Depending 
upon a character or characters sent, the state machine can make a determination whether the communication protocol 
is a text-based protocol, a PPP protocol, or a pre-PPP protocol. The various protocols described immediately herein 
above are well known to the skilled artisan as protocols frequently used as inter-networking protocol used in performing 
out-of-band connection over, e.g., a phone line or direct serial connection. It is the ability to service many protocols 
from a remote terminal, and to detect the incoming protocol that defines an advantage hereof. Thus, regardless of the 
protocol sent, the processor is configured to act upon and forward the communication information to the controller 
memory. The controller memory can thereby dispatch various video screen sequences in response to directives em- 
bodied upon the communication protocol. 

The detection logic, controller memory, processor and communication unit are compiled as a system configured 
upon a PCB. If power to the server should fail, then the primary power supply to the PCB via the expansion bus will 
also fail. The PCB is configured, however, to maintain certain vital functions even if power from the expansion bus 
ceases. The PCB employs a secondary power supply, or battery, which supplies power to the processor and controller 
memory, and selectively to the communication unit when expansion bus power ends. The battery will maintain processor 
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and controller memory activities as well as communication therebetween for a period of time sufficient to sustain video 
screen information stored within the controller memory. !f the communication unit is not being accessed by a remote 
terminal, then power from the battery to the communication unit is terminated. Thus, decoupling circuitry is present 
which prevents unnecessary drain upon the battery if the communication unit is not being used. A first decoupling unit 

s is present between a plane (or portion) of the PC upon which the processor and the controller memory reside and a 
plane of the PCS upon which the communication unit resides. Another decoupling unit is present between the processor 
and controller memory plane and the plane of the PCB upon which the detection logic resides. The detection units 
thereby serve not only to decouple power between planes, but also to decouple signal conductors sent between planes. 
Decoupling power and tri-stating signals between pianes heips preserve the charge upon the battery power source so 

to that power needed to maintain the storage sequences of video screen changes during the server downtime is maxi- 
mized. 

Other objects and advantages of the invention will be apparent upon reading the following detailed description and 
upon reference to the accompanying drawings in which: 

'5 Fig. 1 is a block diagram of a host server retrofitted with a server controller accessible by a remote terminal, in 

accordance with the present invention; 

Figs. 2a-2c are three screen displays of menus which the server controller forwards to a display screen of the 
remote terminal in response to access from the remote terminal: 

Fig. 3 illustrates portions of the memory address space and I/O address space available to the video memory and 
20 video control registers (within the video controller) shown in Fig. 1 : 

Fig. 4 is a detailed block diagram of the server controller; 

Fig. 5 is a block diagram of various buffers used by the processor shown in Fig. 4 to process and store sequences 
of video screens sent to the expansion bus from the server CPU; 

Figs. 6a and 6b are flowcharts illustrating steps taken by the server controller in storing certain sequences of video 
25 screens; 

Fig. 7 is a flowchart illustrating steps taken by the processor of Fig. 4 to replay a reset sequence of video screens 
on the remote terminal: 

Fig. 8 is a flowchart illustrating steps taken by the processor of Fig. 4 to replay a failure sequence of video screens 
on the remote terminal; 

30 Figs. 9a-9c represent a sequence of displays presented as an exemplary sequence of failure screens; 

Fig. 10 is a timing diagram of various EISA expansion bus signals, indicating two separate video write cycles in 
which expansion bus intrusion and non-intrusion occur; 

Fig. 11 is a flowchart illustrating steps taken by the server controller to detect various communication protocols 
useable by the remote terminal; 
35 Fig. 12 is a state diagram illustrate a text protocol state machine used in detecting text communication protocol 

sent from the remote terminal; 

Fig. 13 is a state diagram illustrate a pre point-to-point (PPP) protocol state machine used in detecting pre-PPP 
communication protocol sent from the remote terminal; 

Fig. 14 is a state diagram illustrate a PPP protocol state machine used in detecting PPP communication protocol 
40 sent from the remote terminal; 

Fig. 15 is the server controller embodied upon a PCB adapted for coupling onto an expansion bus; 

Fig. 1 6 is comparator logic used in decoupling signal conductors extending between power pianes arranged within 

said PCB of Fig. 15; and 

Fig. 1 7 illustrates signals used to couple signal conductors and power to a communication unit power plane during 
•*s times when the communication unit is receiving a signal from a remote terminal. 

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are 
shown by way of example in the drawings and will herein be described in detail. 

Referring now to Fig. 1, a block diagram of a computer system 10 is shown. Computer system 10 preferably 

50 includes any system which stores and retrieves files, a suitable system being a file server, an application server, or 
any other server known in a distributed computing system. System 10 includes a host central processing unit ("CPU") 
1 2 coupled to a memory controller 1 4 via a CPU local bus. CPU 1 2 includes any data processing unit which implements 
a predetermined instruction set and has basic features of, inter alia, execution units, control/timing units and various 
registers. Exemplary CPU 12 includes the Pentium® processor manufactured by Intel Corp. 

55 ' Memory controller 14 orchestrates the transfer of data between the CPU local bus and system memory 16. Memory 
controller 1 4 responds to various addressing techniques, and is configured to support various storage cell architectures 
within system memory 16, suitable architectures being dynamic random access memory ("DRAM") or static random 
access memory ("SRAM"). Memory controller 14 preferably operates synchronously with CPU 12 to ensure maximum 
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transfer bandwidth to and from system memory. According to one embodiment. CPU 12 is coupled to a peripheral 
component interface ("PCI") bus. A bus interface unit 16 operates as a bus bridge between the PCI bus and an ex- 
pansion bus. Bus interface unit 18 includes a buffer to control the transfer of data and address signals between the 
PCI bus and the expansion bus. Bus interface unit 18 thereby interfaces between data sent over buses operating at 
5 possibly different clock speeds and with dissimilar protocols. Preferably, the expansion bus comprises an extended 
industry standard architecture ("EISA") bus configuration. 

Connected to the expansion bus is a video controller 20. Video controller 20 is used to control an electronic display 
24 connected thereto. Video controller 20 is indicative of commonly used video controllers such as video graphics 
array ("VGA") controllers. Video controller 20 responds to addresses upon the expansion bus and forwards corre- 
to spending data to video memory 22. Video memory 22 stores video data to be displayed by the video controller upon 
electronic display 24. Display 24 includes any console or monitor which can receive video data, a preferred display 24 
is a cathode ray tube ("CRT") or, alternatively, a liquid crystal display ("LCD"). Video controller 20 and video memory 
22 are henceforth referred to collectively as a video subsystem. 

Server 10 is retrofitted with a mechanism for saving sequences of video screen changes prior to server 10 failure 
'5 as well as sequences of video screen changes after server 1 0 reset. The mechanism for doing so must be unaffected 
by power loss to the server, and must have the ability to forward the stored video screens to a remote terminal. Such 
a mechanism is provided by a server controller 26. Server controller 26 is coupled within the chassis of server 1 0, and 
is connectable to the expansion bus, wherein controller 26 is accessible from a terminal located remote from server 
10. According to a preferred embodiment, remote terminal 28 is coupled to server controller 26 via telephone line 
20 communication devices, such as a modem contained in both remote terminal 28 and server controller 26. Remote 
terminal 28 includes a display apparatus (e.g., a CRT) and an input device (e.g., a keyboard). 

According to one embodiment, server controller 26 operates from software available from Compaq Computer Corp. 
Specifically, Compaq offers a software product entitled Compaq Insight Manager ("CIM") which can operate upon 
remote terminal 28. CIM can access firmware loaded into server controller 26 for performing, e.g., replay of the various 
25 video screen changes stored in server controller 26. 

Hardware and firmware features of server controller 26 make available remote access and control by a remote 
terminal configured with CIM. Hardware and associated code added to server controller 26 allow a system administrator 
to dial into the server controller 26 after server 10 has failed, and thereafter communicate with the server controller 26 
to view the sequences of display 24 screen changes that occurred prior to that failure and after reset. 
30 The firmware or code within server controller 26 resides as console application code used to communicate with 

remote terminal 28. Fig. 2a is a screen display of the initial menu screen which the console application displays upon 
remote terminal 28. The screen displays occur whenever the system administrator dials into server controller 26. The 
administrator can choose from any of the menu items. If he or she chooses menu item four, then the administrator can 
view, at his or her remote terminal 28, the sequence of video screens stored within server controller 26. Three different 
35 sequences of video screen changes may be played: (I) a sequence of video screens which occur after a prior reset of 
server 10, (ii) a sequence of video screens which occur after a current reset of server 10, and (iii) a sequence of video 
screens which occur prior to a failure of server 10. The aforementioned sequence of video screens are herein referred 
to as current reset sequence, prior reset sequence and failure sequence (collectively "playback sequences") . 

Fig. 2b is a screen display of a menu screen which the system administrator can use to instruct server controller 
-to 26 to display any of the aforementioned sequences. Fig. 2c is a screen display of a menu screen which the system 
administrator uses to instruct the server controller 26 to start, pause, or change the speed of the playback of any of 
the current reset, prior reset and failure screen sequences. 

The current reset screen sequence consists of a sequence of video screen changes that occur immediately after 
the most recent reset of server 10. The previous reset sequence consists of a sequence of video screen changes that 
4 $ occur immediately after a reset which occurred prior to the most recent reset of server 1 0. The failure sequence consists 
of a sequence of video screen changes that occur just prior to a reset, failure or power down of server 1 0. The number 
of screen changes which the server controller 26 stores prior to a reset or power down of the server 10 for a failure 
sequence or subsequent to a prior or current reset sequence is determined by the amount of buffer space available in 
the server controller 26 for the given playback sequence. 
so Referring now to Fig. 3, portions of the memory address space and I/O address space in server 10 are shown. 

The memory address range OxBOOOO through OxBFFFF is reserved for video frame buffers which reside within video 
memory 22. The I/O address ranges 0x03B4 through 0x03BA and 0x03C0 through 0x03DA are designated for video 
control registers within video controller 20. CPU 1 2 writes values to the video control registers to control various aspects 
of display 24. The frame buffer memory address range and the video control register I/O address range are herein 
55 collectively referred to as video address ranges, or address ranges for data sent to the video subsystem. 

Display 24, when in text mode, is organized into a matrix of rows and columns. For example, a common display 
screen configuration is 25 rows by 80 columns. Thus 2000 (i.e., 25 x 80) character locations are available on display 
24. Each location on display 24 has an associated word (i.e., two bytes) in the frame buffer. The low byte of the word 
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contains the character value (such as a 0x41 for the character "A" in the ASCII character set) and the high byte of the 
word contains an associated attribute (such as the colour foreground and background intensity, whether or not the 
character is blinking, etc.). CPU 12 writes values to the appropriate frame buffer locations within video memory 22 to 
display the desired characters and attributes on display 24. The video data in the frame buffer comprising characters 
and attributes for display is herein referred to as display data. In the above example, 4000 bytes (2000 locations x 2 
bytes per location -- one for the character and one for the attribute) of the frame buffer are used to store display data 
representing an entire display screen. 

The following three examples illustrate some of the many uses of the video control registers, whose addresses 
are reserved within the I/O address space. First. CPU 1 2 writes to the video control registers (i.e.. within address ranges 
0x03B4 to Ox03BA t or within address ranges 0x03C0 to 0x03DA) to control, e.g., the location and attributes of the 
cursor on display 24. Second, the CPU 12 writes to the video control registers to change, e.g., the video mode from 
colour mode to monochrome mode or vice versa. Third, the video control registers can specify a start address in video 
memory 22 from which multiple screens can be stored. In the third example, an assumption is made whereby video 
memory 22 contains more storage locations than are needed to store one screen of display data. Assuming that video 
memory 22 contains 64KB of memory (i.e., 64KB are available for the frame buffers), then possibly only 4000 bytes 
of the frame buffer are used to store a screen of display data. Thus, the frame buffer may accommodate multiple sets 
of display data at a time. CPU 12 writes to the video control registers to specify the start address in video memory 22 
of the first set of display data to be displayed on display 24. Information regarding video controllers and more specifically 
VGA controller which employ video control registers for performing many of the above exemplary control functions is 
obtainable from, inter alia, Cirrus Logic Corp., part no. CL-GD542x. 

Video controller 20 decodes the addresses generated on the expansion bus (preferably EISA bus) and responds 
to bus cycles in the video address ranges. Video controller 20 not only sends to display 24 the display data stored 
within the video memory 22, but also controls the display 24 in response to data written by CPU 12 into the video 
control registers. Video memory therefore contains character and attribute information, whereas video control registers 
contain information to control display 24 

Similar to video controller 20, server controller 26 also decodes the addresses on the expansion bus in order to 
detect writes to the video subsystem. When it detects a write to the video address ranges, server controller 26 stores 
the data written to the video address ranges within the server controller 26. This operation is referred to as "snooping". 
That is. server controller 26 obtains one or more screens of display data intended for another subsystem (i.e., video 
subsystem 20 and 22). Data is duplicated upon server controller 26 such that server controller 26 maintains a mirror 
copy of information within frame buffers of video memory 22 as well as information within video control registers of 
video controller 20. Snooping the expansion bus for digital signals within the video address range allows duplicative 
stores to occurs, even though CPU 12 perceives only one write to the video subsystem. Importantly, snooping is per- 
formed by server controller 26 in a non-intrusive manner. Data intended for the video subsystem proceeds onto the 
video subsystem and is not modified or removed by server controller 26. 

Referring now to Fig. 4, a detailed block diagram of server controller 26 is shown. Server controller 26 comprises 
detection logic 30 coupled to the expansion bus. Controller memory 32 is coupled to detection logic 30 via a controller 
bus. Detection logic 30 comprises combinatorial and sequential logic elements such as those commonly found, for 
example, in programmable array logic ("PAL") circuits. Details regarding control logic 40, address buffers 42 and data 
transceivers 44 will be provided after a discussion of their relevance. In particular, the three units within detection logic 
30 gain significance given full appreciation to the capabilities of the various components of the server controller 26 and 
specifically the significance of controller memory 32 and the various buffers therein. Therefore, description of units 40, 
42 and 44 will be forestalled until after a discussion of the playback sequences and how various buffers store those 
sequences. As part of server controller 26, a processor 34 is needed to orchestrate information upon the controller 
bus — either information between detection logic 30 and controller memory 32, or information between communication 
unit 36 and controller memory 32. Processor 34 includes any microprocessor or microcontroller responsive to an in- 
struction set and containing, e.g., an execution unit, memory, input/output devices, and one or more registers. Processor 
34 is indicative of microprocessors used for embedded system applications. The controller memory 32 comprises a 
plurality of digital storage elements. In one embodiment the controller memory 32 comprises pseudo-static RAM. Com- 
munication unit 36 includes any device which can communicate to remote terminal 28 configured remote from server 
controller 26. Communication unit 36 responds to an analog ring signal (ARNG) sent from remote terminal 28, by 
producing a communication signal (COMM. SIG) back to remote terminal 28. Preferably communication unit 36 com- 
prises a modem. Communication unit further contemplates a serial port coupled to processor 34 and a modem coupled 
to the serial port external to server controller 26 for communicating with the remote terminal 28. 

Processor 34 stores the playback sequences in controller memory 32. Processor 34 could store the playback 
sequences as sequences of display data representing an entire set of display screens within controller memory 32. 
However, this would be a relatively inefficient way to use the controller memory 32 and thus the number of video screens 
stored within controller memory 32 comprising the playback sequences would be relatively small. In the present inven- 



EP 0 825 535 A2 



lion, processor 34 advantageously processes display data to efficiently store the playback sequences as a sequence 
of display "changes" instead of a sequence of entire display screens. The amount of display data representing changes 
within a screen is substantially less than the amount of display data representing an entire screen. Thus, the sequence 
of current reset screens, the sequence of prior reset screens and the sequence of failure screens (i.e.. playback se- 

5 quences) are represented as changes from a reference or "start" screen. 

Referring now to Fig. 5. various buffers within controller memory 32 are shown. Those buffers are used by processor 
34 to process and store the playback sequences. A local frame buffer 48 contains the display data snooped during 
write accesses to video memory 22. That is, detection logic 30 snoops the expansion bus and stores the data destined 
for the video subsystem into the local frame buffer 48. A snapshot buffer 50 contains a copy or snapshot, created by 

'0 the processor 34, of the current display data from the local frame buffer 48. A temporary snapshot buffer 52 also 
contains a snapshot of the current display data from the local frame buffer 48. The temporary snapshot buffer 52 is 
used to make the playback sequences more legible in the event that screen changes, in particular screen scrolls, are 
rapidly made. 

A current reset sequence buffer 54 contains information associated with the most recent reset sequence. That is, 

'5 the current reset sequence buffer 54 contains the screen changes beginning with the most recent reset and ending 
when the current reset sequence buffer 54 becomes full. Screen changes which occur after the current reset sequence 
buffer 54 is full are ignored. The previous reset sequence buffer 56 contains information associated with the reset 
sequence just prior to the most recent reset sequence. That is, the previous reset sequence buffer 56 contains the 
screen changes beginning with a reset which occurred prior to the most current reset and ending when the previous 

20 reset sequence buffer 56 becomes full or when the next reset occurs. Screen changes which occur after the previous 
reset sequence buffer 56 is full are ignored. 

A current sequence buffer 58 contains as many of the most recent screen changes that will fit within buffer 58. A 
failure sequence buffer 60 contains information associated with the failure sequence just prior to the most recent reset 
of server 10. That is, failure sequence buffer 60 contains the screen changes ending with the most recent reset and 

25 contains as many of the screen changes occurring just prior to the most recent reset that will fit therein. 

The failure start buffer 64 contains display data of a video screen display associated with failure sequence buffer 
60. The failure start buffer 64 contains the initial screen image (or "reference" display screen) in the failure playback 
sequence and consequently the screen image to which the first change in the failure sequence buffer 60 is applied. 
Initially the failure start buffer 64 is a blank screen. If and when the failure sequence buffer 60 overflows, the overflow 

^0 changes are converted to characters and attributes and stored in the failure start buffer 64. Thus : the failure start buffer 
64 provides a more useful initial screen image in the event where only a few characters on the screen changed many 
times over a relatively long period of time. The current start buffer 62 serves the same function relative to the current 
sequence buffer 58. 

It is noted that a reset or failure of server 10 does not cause a reset of server controller 26. However server 
35 controller 26 detects and maintains information concerning the following reset events: power on of server 10, power 
off of server 10, and reset of the expansion bus. In particular, server controller 26 does not respond to the RSTDRV 
EISA bus signal, but merely detects the assertion of RSTDRV. If a reset occurs, or if power is removed from server 
10, server controller 26 nonetheless maintains operation in order to preserve the playback sequences for display on 
the remote terminal 28. A secondary power supply is furnished on the same PCB which houses server controller 26 
-to to ensure the playback sequences are maintained. If desired, however, servercontroller 26 may be reset under software 
control by writing a predetermined sequence of values into predetermined register locations of the server controller 26 
which are accessible to the CPU 12. 

When a server 10 reset occurs, pointers are changed so that the current reset sequence buffer 54 becomes the 
previous reset sequence reset buffer 56 ; and previous reset sequence buffer 56 is flushed and becomes the current 
reset sequence buffer 54. A server reset also causes the current sequence buffer 58 to become the failure sequence 
buffer 60. and failure sequence buffer 60 is flushed and becomes the current sequence buffer 58. Also on reset, the 
current start buffer 62 becomes the failure start buffer 64 and the failure start buffer 64 is flushed and becomes the 
current start buffer 62. 

Server controller 26 is configured to perform an automatic server recovery ("ASR") reset of server 1 0. When the server 
50 controller 26 detects a failure of server 10, it waits a predetermined amount of time (typically 30 seconds) and resets 
server 10. 

The following is an exemplary sequence of a reset, followed by a failure, followed by a reset on server 1 0. Server 
10 is first powered on which causes server 10 to reset. On reset, servercontroller 26 flushes information from previous 
reset sequence buffer 56, flushes failure sequence buffer 60 and flushes failure start buffer 64. During flushes of buffers 
55 56, 60 and 64, a swap of previous reset sequence buffer 56 and the current reset sequence buffer 54 occurs simulta- 
neous with swaps between buffers 60 and 58 as well as swaps between buffers 64 and 62. Thus, reset causes move- 
ment of information from buffers 54, 58 and 62 to buffers 56, 60 and 64, respectively. On reset, server 10 software 
begins performing the POST operations and displaying characters on display 24. Server controller 26 stores the screen 

I 



7 

BNSOOdD: <£P__p826636A4JL> 



EP 0 825 535 A2 



changes associated with the POST operations in current reset sequence buffer 54 and current sequence buffer 58. 
Once the current reset sequence buffer 54 becomes full, the server controller 26 stops storing screen changes thereto. 
If the current sequence buffer becomes full, the server controller 26 removes the oldest screen changes from the 
current sequence buffer 58 to make room for the new screen changes and modifies the current start buffer 62 to reflect 
5 the old screen changes. Thus, buffer 58 performs similar to a FIFO register, with overflow information sent to buffer 
62. As described below, a combination of buffers 58 and 62 (when swapped with buffers 60 and 64) depict the entire 
failure sequence of video screens prior to the most recent failure. 

When a failure of server 1 0 occurs, in accordance with the second step in the reset-failure-reset three-step example, 
a sequence of video screens occur upon display 24 indicative of that failure and possibly the cause of thai failure. 

to These screens are automatically displayed as part of many server operating systems available as ABEND messages 
from Novell Netware or a Microsoft NT blue screen. Thirty seconds after failure occurs, server controller 26 performs 
an ASR reset on server 10. Thus, the second reset within the reset-failure-reset example occurs during ASR reset. 
The reset, similar to the first reset, enables server controller 26 to flush buffers 56 ; 60 and 64 while swapping buffers 
56, 60 and 64 with buffers 54 ; 58 and 62, respectively. Similar to the first reset, server 1 0 again initiates POST operations 

'5 and forwards characters to display 24. Server controller 26 stores the screen changes occurring after reset, resulting 
from POST operation, in current reset sequence buffer 54 and current sequence buffer 58. Previous reset sequence 
buffer 56 now contains the sequence of screen changes associated with the initial power on reset, and the failure 
sequence buffer 60 as well as failure start buffer 64 now contain the sequence of screen changes leading up to that 
failure. As opposed to the initial reset contained within the previous reset sequence buffer 56, current reset sequence 

20 buffer 54 contains the reset associated with the second reset (or ASR reset). 

Video screen changes, as opposed to the entire video screen, are stored as packets in the current reset sequence 
buffer 54 : previous reset sequence buffer 56, current sequence buffer 58 and failure sequence buffer 60. Each packet 
in buffers 54, 56, 58 and 60 consists of a series of bytes of a specified length. Packets are classified according to a 
"type", and the packet type is determined by its length along with the first byte (byte 0), and second byte (byte 1 ) if the 

25 packet length is greater than one. The packet types ; and the resulting action of server controller 26 upon remote 
terminal 28 : are as follows: 





Packet Type 


Action 


30 


Graphics mode: 


Display a "host is in graphics mode" message. 




Bad text mode 


Display a "host in an unsupported text mode" message. 




Server off: 


Display a "host is powered down" message. 




Screen scroll up: 


Scroll the screen up a certain number of lines. 




Clear screen: 


Clear the screen. 


35 


Move cursor: 


Move the cursor. 




Valid text mode: 


Reflect valid text mode change. 




Single character: 


Display a character once. 




Repeat character: 


Display a character a certain number of times. 


40 


Display string: 


Dispfay a null terminated string. 



The binary code format used for each packet type listed above is as follows: 



Packet Type 


Length 


byteO 


byte 1 


byte 2 


byte 3 


byte 4 


Graphics mode: 


1 


0 










Bad text mode: 


1 


1 










Server off: 


1 


2 










Screen scroll up: 


1 


128+lines 










Clear screen: 


2 


0 


attr. 








Move cursor: 


2 


row 


column 








Valid text mode: 


3 


color/mono 


rows 


cols. 






Single character: 


4 


char 


attr. 


row 


column 




Repeat character: 


5 


char 


attr. 


row 


column 


count 


Display string: 


6+ 


attr. 


row 


col. 


charO 


charl... 



Bytes 3 and 4, and any subsequent bytes in the display string packet type contain a null terminated string to display. 
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This string must be at least two characters in length plus the null termination so that its length is greater than 5 and 
thus distinguishable from a repeat character packet using the length test. If the change only contains one character 
then the change is stored as a repeat character packet with a repeat count of one or a single character packet. 

The function of the various buffers residing in the controller memory 32 shown in Fig. 5 will become more apparent 
5 in the discussion of the flowchart of Figs. 6a and 6b. Figs. 6a and 6b are flowcharts illustrating steps performed by 
processor 34 to process display data forwarded to buffers 48-52 as well as to store playback sequences amongst 
buffers 54-54. 

Referring to Fig. 6a. step 70 illustrates processor 34 checking the local frame buffer 48 to see if any video mode 
changes have been made via the video control registers. Examples of video mode changes are a change between 
'0 graphics and text mode or a change in the screen size, i.e., change in the number of rows and/or columns of a display 
unit. Before playback sequences can be stored, processor 34 must determine in step 72 if the current video mode is 
a valid text mode. If not. processor 34 waits until the video mode becomes a valid text mode before processor 34 copies 
the current display set (indicated by the start address specified in the video control registers) from the local frame buffer 
48 to the temporary snapshot buffer 52 in step 74. 
>s Processor 34 then compares the contents of the temporary snapshot buffer 52 with the contents of the snapshot 

buffer 50 to determine if a screen scroll has occurred in step 76. If a scroll has occurred, processor 34 stores a screen 
scroll packet to the appropriate buffers in step 78. 

Processor 34 can then begin a sequence of steps to start at the beginning of the snapshot buffer 50 and temporary 
snapshot buffer 52 and compare them for changes. Processor 34 compares the current bytes of buffers 50 and 52 and 
20 looks for a change in step 80. If a change is found, as shown in step 82. then processor 34 updates in step 84 the 
snapshot buffer 50 with the change. Processor 34 then converts the change into a packet in step 86. It is the change, 
as applied to a packet, that is selectively placed into current buffers 54, 53 and 62 in step 88. Processor 34 then returns 
to step 60 to look for another change and repeats steps 82, 84, 86 and 88 until in step 82 processor 34 determines 
that there are no more changes between the display data in buffers 50 and 52. 
25 Once processor 34 has determined that there are no more changes in step 82, processor 34 determines if the 

cursor has changed positions in step 90. If so, the processor 34 stores a move cursor packet into the current buffers 
54 : 58 and 62 in step 92 in a manner similar to that performed in step 88. If the cursor has not changed, then a packet 
rewrite to the existing cursor location is performed. 

Referring now to Fig. 6b, a more detailed description of the steps taken to perform step 88 of Fig. 6a are shown. 
30 Processor 34 determines if the current reset sequence buffer 54 is full in step 94. That is, step 94 indicates if packets 
sent to buffer 54 has caused that buffer to become full. If buffer 54 is not full, then processor 34 forwards the present 
packet to the current reset sequence buffer 54 in step 96. Step 98 indicates whether processor 34 determines if current 
sequence buffer 58 is too full to receive another packet. If so, processor 34 removes the oldest packet from the current 
sequence buffer 58 in step 1 00, and thereafter converts the oldest packet into a character/attribute word. The character/ 
35 attribute word of the removed packet is then forwarded to the current start buffer 62 in step 102. Processor 34 repeats 
steps 98. 100 and 102 until it determines in step 98 that the current sequence buffer 58 is not too full to receive the 
packet, at which time processor 34 puts the packet into the current sequence buffer 58 in step 104. 

Following is a code fragment of C language function, find_changes(), which can be used by processor 34 to peri- 
odically execute the functions set forth in the flowchart of Fig. 6a: 

40 



45 



50 



55 
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w 



25 



30 



35 



45 



50 



* f ind_changes ( ) 

* This routine is called repeatedly to find the screen changes and 

* store them in the various buffers. 

*#***********##*#**»*********#**#****#****#*****#****************##********* J 

PRIVATE int f ind_changes { void) 
{ 

if (vga mode changedf)) { 



/* 

VGA mode is different but may be in the middle of a change so delay 

for awhile to allow it to finish 
is */ 

wait(DELAYJTIME) ; 

if ( vga_mode_changed ( ) & <VGA_UPDATE_MODE | VGA_UPDATE_ROWS | 
20 VGAJJPDATE_COLUMNS | VGA_UPDATE_VALID_STATUS) ) { 

/* — 

current VGA mode or screen dimensions have changed or the valid 
text mode status has changed so refresh screen 



NOTE: It is not necessary to store the entire screen if only the 
starting address changes. 
*/ 

/* store the mode change and refresh the screen */ 
refresh_screen{ ) ; 

} 

} 

if (vga_valid_textjnode( ) ) {/* if a valid text mode */ 

/* 

copy the local frame buffer into the temporary snapshot buffer for 
comparison with the snapshot buffer 

NOTE: This copy is used for comparison rather than the actual 
local frame buffer to make fast scrolls more legible. 
/ 

memcpy { temp_snapshot_buf , local_f rame_buf f er , buf f er_size ) ; 

/ 

check if the screen has scrolled up 
./ 

scroll = detect_scroll ( ) ; 
if (scroll) { 

/* store scroll */ 

put_scroll__up( scroll, update buffers) ; 



55 
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/ 

scan through the entire screen comparing the local frame buffer 
with the last snapshot taken, convert any differences to 
packets, and put these packets into the current destination buffers 
and update the snapshot buffer 

/ 

vidasmjcan ( temp_snapshot_buf , snapshotjouf , buf f er_size , number_columns ) ; 

/* 

update cursor position 



/* read cursor position */ 

error = vga_cursor_position ( ficursor ) ; 

/* compare with last updated position */ 
if { 1 error && ((cursor. row 1= cursor_row) || 
{cursor - column t= cursor_column) ) ) { 
put_cursor (cursor . row, cursor . column, update_buf f ers ) ; 



return 0; 

} 



Following is a code fragment of C language function, put_packet(), which can be used by processor 34 to period- 
ic really execute the functions set forth in the flowchart of Fig. 6b. 



y**************************************************************************** 

* put_packet ( ) 

35 * 

* This routine stores a packet in the reset and failure buffers. 
********************** ^*^***^***************************************/ 

PRIVATE void put_packet { char * packet, int length, int destination) 

{ 

40 char temp_packet [MAX_PACKET_SIZE] ; /* packet retrieved to make room */ 

int temp__length; /* temp packet length */ 

/ 

store packet in buffers 

45 */ 

if (destination & RESET_SEQUENCE_BUFF) { 

/* 



SO 



55 



NOTE: this put does nothing if the buffer is full. 
*/ 

buf fer_put_packet (packet, length, reset_ptr) ; 

> 

if (destination & FAILURE_SEQUENCE_BUFF) { 

while (buf fer_put_packet( packet, length, failure_ptr) ) { 
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15 



35 



I 

buffer full so need to make room for the packet 



if ( ibuf f er_get_packet { temp_packet, &temp__length, f ailure_ptr ) ) { 
/* put overflow in FAILURE_START_BUFF */ 
play_packet ( temp_packet , temp_length, &f ailure_start ) ; 
f ailure_dirty_bits [ current_f ailure ] = 1; 

> 

else { 

/* failure buffer empty so can't make any more room */ 
break; 

} 

> 



20 

Referring now to Fig. 7, a flowchart illustrating steps taken by processor 34 to replay a reset sequence of video 
screens on the remote terminal 28 is shown. The administrator first determines whether the current reset sequence or 
previous reset sequence is desired to be replayed. Processor 34 responds by choosing the current reset sequence 
buffer 54 or the previous reset sequence buffer 56.. respectively, as the reset buffer to be replayed. When the system 

25 administrator instructs the server controller 26 to replay one of the reset sequences, the processor 34 determines in 
step 106 if there are more packets in the reset buffer to display. If so, processor 34 retrieves the next packet from the 
reset sequence buffer and converts the packet to a character sequence in step 108. Processor 34 then displays the 
character sequence on the remote terminal 28 by transmitting the character sequence to the remote terminal 28 in 
step 110. Processor 34 repeats steps 106, 108, and 110 until processor 34 determines in step 106 that there are no 

30 more packets to display. 

Following is a code fragment of C language function, video_reset_play(), which can be used by processor 34 to 
periodically execute the functions set forth in the flowchart of Fig. 7. 



* video_reset__play ( ) 
* 

* This routine reads the next packet from a reset buffer and displays 



40 



45 



SO 



55 



BNGOOCf D: <£P_j0a26636A2JL> 



12 



EP 0 825 535 A2 



* it on the remote screen. Note that the packet is not removed from 

* the buffer. Call video_reset_rewind ( ) to start playback from the 

* beginning of the buffer again. 

**** *********** ******* ***** *********************/ 

PUBLIC int video_reset_play ( void) 
{ 

char packet [ MAX_PACKET_SI ZE ] ; 
int length; 
int error =0; 
unsigned long rc; 

/ 

read packet from buffer (does not remove the packet from the buffer) 
2 / 

if (buf fer_peek_packet(reset_location, packet, &length,reset_buf f ) ) { 

/ 

buffer empty so no packet received. 
*/ 

error = 0 ; 

} 

else { 

/* 

buffer not empty so display the retrieved packet 
*/ 

reset location**; /* go to next location */ 

play_packet (packet , length) ; /* display the packet */ 
error = 1; 

> 

return error; 

} 

Referring now to Fig. 8, a flowchart illustrating steps taken by processor 34 to replay a failure sequence on remote 
terminal 28 is shown. When the system administrator instructs the server controller 26 to replay the failure sequence, 
processor 34 determines in step 112 if there are more characters in the failure start buffer 64 to display. It is noted that 
current start buffer 62 and failure start buffer 64 contain characters (i.e., words comprising character/attribute pairs) 
instead of packets found within buffers (i.e., buffers 54-60) which store screen changes as opposed to the screens 
themselves. If there are more characters in buffer 64 to display, processor 34 retrieves the next character from the 
failure start buffer 64 and displays the character on remote terminal 28 by transmitting the character to the remote 
terminal 28 in step 114. Processor 34 repeats steps 112 and 114 until processor 34 determines in step 112 that there 
are no more characters in the failure start buffer 64 to display. It is noted that a character is not removed from the failure 
start buffer 64; instead, a copy of the character is taken. 

Once processor 34 determines in step 1 1 2 that all of the characters in the failure start buffer 64 have been displayed, 
processor 34 searches for further packets in the failure sequence buffer 60 to be displayed in step 116. If there are no 
further packets, processor 34 has then concluded replaying the failure sequence. Otherwise, the processor 34 converts 
the packet to an ANSI character sequence in step 118. Processor 34 then displays the character sequence on remote 
terminal 28 by transmitting the character sequence to remote terminal 28 in step 1 20. Processor 34 repeats steps 11 6, 
1 1 8 and 1 20 until it determines in step 1 1 6 that all of the packets in the failure sequence buffer 60 have been displayed. 

Following is a code fragment of C language function, video_failure_play(), which can be used by processor 34 to 
periodically execute the functions set forth in the flowchart of Fig. 8: 
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25 



* ******** **************** **************** 

* * * 

* video_f ailure_play ( ) 
* 

* This routine reads the next packet from the failure sequence buffer 
and 

* displays it on the remote screen. Note that the first rows*columna 

* times this function is called, it displays the next character from 

* the failure start buffer. After the entire failure start buffer has 
been 

* displayed, packets are then read and displayed from the failure 
sequence 

* buffer. Packets are not removed from the buffers. 

* Call video_f ailure_rewind{ ) to restart the playback from the 
beginning. 

************************************************************************* 
**/ 

PUBLIC int video_f ailure_play (display_screen* screen) 
{ 

char packet [ MAX_PACKET_S IZE ] ; 
char character; 

int attribute, fore, back, rows, columns; 
int length; 
int error; 



30 
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25 



35 



40 



unsigned long rc; 

/ — 

set screen dimensions for 1st time through 

•/ 

•i 

if ( { failure_row ==1) && ( f ailure_column == 1) && ( f ailure_location « 
1)) { 

if (display_screen_d intensions ( &last_f ailure_start , firows, Scolumns) == 

0) { 

/* last_f ailure_start is valid */ 
display_change_dimensions ( rows , columns , screen ) ; 

> 

} 



/* — 

20 determine current display screen dimensions 

*/ 

display_screen_dimens ions { screen, firows, Scolumns) ; 

/* 

first display visible portion of the failure start buffer 

30 1 

while { ( f ailure_row <= VGA_ROWS_MAX ) &£ 

( idisplay_row_visible{ f ailure_row, screen) ) ) { 

/ 

while still within the buffer but the row is not visible 

Note: This loop is used to skip rowe that are not visible, i.e. 

the bottom ( VGA_ROWS_MAX - 25) rows if the display screen 

only 

has 25 rows, 

*/ 

45 f ailure_row++; 

failure_column = 1; 

} 

if <failure_buffer_dirty && <failure_row <= VGA_ROWS_MAX ) ) { 

50 /* 

the failure start buffer still has changes which will be visible 

on 

the display screen. Read the next character from the buffer. 
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character « VGA_READ_CHARACTER ( f ailure_row, f ai lure_column , 

failure atart_buf fer .params. vga) ; 
attribute = VGA_READ_ATTRIBUTE( £ailure_row, f ailure_column, 

failure_start__buffer.parama.vga) ; 
VGA ATTRIBUTE_TO_COLOR ( attr ibute , & f ore , &back ) ; 

/* 

display this character 

V 

display_character< character, fore, back, f ailure_row, f ailure_column, 1 , 
screen) ; 

/ 

go to next column handling wrap-around 

«/ 



f ailure_column++ ; 

if ( f ailure_column > columns) {/* end of line */ 
25 failure_column = 1; 

failure_row++; 

> 

error = 1;/* character displayed */ 

> 

else { 



/- 



the failure start buffer has no more visible changes. Get next 
packet from failure sequence buffer. 



if (buff er_peek_packet(failure_location, packet, Slength, last_f ailure_ptr ) ) { 

40 

, 

buffer empty so no packet received. 

45 1 

error « 0; 
else { 

50 /* 

buffer not empty so packet received. 



55 

failure location**; /* go to next location */ 



BN80OC1D: <£P_0a2663OA2JL> 



16 



EP 0 825 535 A2 



play_packet {packet , length, screen) ; /» display the packet */ 
error » 1; 

> 

} 

return error; 

> 

Playback of playback sequences begins when the administrator presses the space key in response to the menu 
shown in Fig. 2c. Playback consists of a stream of characters and escape sequences sent to the remote terminal to 
display the information in the sequence buffers. Each displayabie character (ASCII values 32-1 26 and 1 28-254) is sent 
to remote terminal 28 as an 8-bit ASCII value. Some characters (ASCII values 0-31 and 127) are control characters 
that do such things as ring a bell rather than displaying an actual character. As a result, if one of these non-displayable 
characters appears in the local frame buffer 48. it is actually sent to the remote terminal as either a space or a similar 
looking displayabie character. An escape sequence (a sequence of characters starting with the escape character (ASCII 
value OxIB) is used to perform other actions such as moving the cursor clearing the screen, and changing the current 
display colour. Server controller 26 transmits all characters unchanged except characters 0-31 , 1 27, 255. These char- 
acters are remapped to the following ASCII bytes: 



32, 


32, 


32, 


32, 


32, 


32 


,32, 


42, 


/* 


chars 


0-7 


*/ 


32, 


32, 


32, 


32, 


32, 


32 


,32, 


42, 


/* 


char 


8-15 


*/ 


62, 


60, 


32, 


33, 


32, 


32 


,32, 


32, 


/* 


chars 


16-23 


*/ 


94, 


118, 


62, 


60, 


32, 


32 


,94, 


118, 


/* 


chars 


24-31 


*/ 


94, 
















/* 


char 


127 


*/ 


32 
















/* 


char 


255 


*/ 



The following are the escape sequences sent by the server controller 26 where \x1 B = ESC character. In the event 
that the Compaq Insight Manager (CIM) application is executing on the remote terminal 28, server controller 26 trans- 
mits certain non-standard escape sequences to communicate with the CIM. Those non-standard escape sequences 
are denoted with an asterisk in the following Table I: 



Table I 



Always used: 






Clear screen; 


\x1b[2J 




Move Cursor: 


\xlb[n:mH 


n = cursor row, m = cursor column (i.e. \x1 b[1 ;2H) 


♦Flint ID: 


\x1b[} 




-Color: 






+Disable hi intensity: 


\x1b[0m 




♦Foreground hi intensity: 


\x1b[1m 




+Black Background: 


\x1b[30m 




Red Background: 


\x1b[31m 




Green Background: 


\x1b[32m 




Yellow Background: 


\x1b[33m 




Blue Background: 


\x1b[34m 




Magenta Background: 


\x1b[35m 




Cyan Background: 


\x1b[36m 




+White Background: 


\x1b[37m 




+Black Foreground: 


\x1b[40m 




Red Foreground: 


\x1b[41m 




Green Foreground: 


\x1b[42m 




Yellow Foreground: 


\x1b[43m 
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Table I (continued) 



Cjiuc r (Ji eyi uui iu. 


\x i hf44m 




Magenta roreyruunu. 


W 1 hfd^m 
\a i u| fji n 




Cyan Foreground: 


\ v 1 Kf A Cm 

\X I D[4om 




♦White Foreground: 


\xl Dl47m 




Combinations of above: 


i.e. \xl b[0, 1 .47.30m 




Only used when talking to CIM: 






'Repeat Character: 


c\x1 b[nb 


c - character to repeat. 






n - repeat count 


'Screen Scroll: 


\x1b[nS 


n = number rows to scroll 


'Set Number Rows: 


\xlb[n- 


n = number of rows 


'Enable Japanese: 


\x1b$B\x1b(B 




'Disable Japanese: 


\x1b[l 




-Color: 






'♦Background hi intensity: 


\x1b[5m 





20 The escape sequences marked with a V character in the above Table I are the only colour escape sequences 

used in monochrome modes. All colours except black and hi intensity black are converted to white or hi intensity white. 

If the server controller 26 is not communicating with the CIM, the hi intensity background colours are not supported 
and are sent as the same colour but normal intensity. If the foreground is this same colour of normal intensity, then the 
foreground colour is remapped so that it will still be visible according to the following Table II: 



25 

Table II 





Colour Modes 


Monochrome Modes 




Black -> Red 


Black -> White 


30 


Red -> Black 


White -> Black 




Green -> Yellow 






Yellow -> Green 






Blue -> Magenta 






Magenta -> Blue 




35 


Cyan -> White 






White -> Cyan 





Referring now to Figs. 9a-9e, screen shots of an exemplary failure sequence are shown. The screen sequence is 
exemplary of a playback sequence displayed by the server controller 26 on the remote terminal 28. Fig. 9a is a screen 
shot of a typical initial screen upon power-up of a server. The screen shows various items regarding the system con- 
figuration. Fig. 9b is a screen shot of a typical WINDOWS NT loader screen. The user is given the opportunity to select 
between a plurality of NT kernels to boot. Fig. 9c is a screen shot of a typical NT boot screen. The screen contains the 
build version of the kernel, the amount of system memory, processor configuration, etc. Fig. 9d illustrates the message 
displayed by the server controller 26 on the remote terminal 28 during a playback sequence when the playback .se- 
quence contains a packet indicating that the server 10 display 24 was placed in graphics mode by the host CPU 12. 
Figure 9e is a screen shot of a typical NT blue screen. 

By snooping the expansion bus (preferably, EISA bus) for writes to the video subsystem, server controller 26 
advantageously obtains video data updates in real time so that replay of the playback sequences can be realized. In 
addition, by snooping the expansion bus for writes to the video subsystem, server controller 26 obtains the video data 
updates in a manner typically non-intrusive to server 10 and, more specifically, non-intrusive to the expansion bus 
bandwidth. Other solutions obtain video data in an intrusive and non-real-time manner. For example, the COMPAQ 
Server Manager/R ("SMR") product asserts mastership of EISA bus cycles to obtain data within video memory 22 of 
server 10. SMR thereby periodically copies a portion of display data from video memory 22 into its own memory. The 
copied data is then compared with a previous copy of the video data to determine screen changes. The bus mastering 
approach of the SMR disadvantageously increases traffic on the EISA bus and adds extra bus arbitration delay toother 
EISA bus masters. 

Referring again to Fig. 4, description of the various blocks 40-44 within detection logic 30 is now provided. Detection 
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logic 30 comprises address buffers 42. data transceivers 44. and control logic 40 coupled between the EISA bus and 
the controller bus. The control logic 40 and processor 34 are coupled by HOLD and HLDA {HOLD Acknowledge) 
signals. The address buffers 42. data transceivers 44. and control logic 40 cooperate to snoop display data and there- 
after write the data to local frame buffer 48 (shown in Fig. 5) which forms a part of controller memory 32. 

Controller memory 32 is a resource shared between processor 34 and detection logic 30, in that both the processor 
34 and the detection logic 30 modify controller memory 32. The controller memory 32 comprises a single-ported pseudo- 
static RAM. Detection logic 30 therefore steals cycles away from processor 34 to write the video data to controller 
memory 32. As write cycles occur to the video subsystem, detection logic 30 decodes the write cycle, puts processor 
34 on hold, and writes the video data into controller memory 32. Server controller 26 writes the video data to controller 
memory 32 concurrently with writing the video data to the video subsystem advantageously sustaining normal video 
activity on server 10. 

Control logic 40 receives the address signals from the expansion bus and decodes the presence of an address in 
the video address ranges. If an address in the video address ranges appears on the expansion bus address signals, 
control logic 40 puts processor 34 on hold by asserting the HOLD signal to the processor 34 to arbitrate for controller 
memory 32. Processor 34 asserts HLDA to grant ownership of the controller bus to control logic 40. 

Control logic 40 must ensure that it will be able to obtain ownership of the controller bus and write the video data 
to the controller memory 32 before completion of the write cycle to the video subsystem. To do so. control logic 40 
makes use of the certain signals within an EISA expansion bus. The control logic utilizes EXRDY signal available to 
an EISA expansion bus. If the expansion bus is an ISA bus, then the control logic utilizes CHRDY signal. In either 
instance, EXRDY or CHRDY function to delay the expansion bus write cycle to the video subsystem until control logic 
40 obtains ownership of the controller bus. 

On the rising edge of the EISA expansion bus (expansion bus) BCLK signal, during assertion of the expansion 
bus STARTS signal, control logic 40 latches the address from the expansion bus address signals. Control logic 40 
examines other control signals on the expansion bus, namely BCLK, STARTS, CMD#, and W_R to determine if the 
bus cycle is a write cycle. If the bus cycle is not a write cycle, then control logic 40 stops arbitrating for the controller 
bus by deasserting the HOLD signal. If the bus cycle is a write cycle, data transceivers 44 drive the video data from 
the expansion bus data signals into the controller memory 32, thereby completing the write cycle on the rising edge of 
the expansion bus CMDS signal. The rising edge of CMD# is delayed if the control logic 40 drives the EXRDY signal low. 

If the arbitration latency (the time between which control logic 40 asserts HOLD and processor 34 granting HLDA) 
exceeds the time needed to setup for a write cycle to the video address ranges, the control logic 40 drives the EXRDY 
signal low on the expansion bus to insert delay cycles, i.e. , to delay the rising edge of CMDS. The EXRDY signal being 
driven low indicates to the master of the expansion bus which is currently performing the write cycle that the recipient 
of the write cycle is not ready to receive the data. Typically, processor 34 grants HLDA to control logic 40 sufficiently 
early so that the control logic 40 does not need to assert EXRDY Thus, server controller 26 snooping is typically non- 
intrusive. 

Control logic 40 translates the address previously latched from the expansion bus address signals to a correspond- 
ing location in the local frame buffer of controller memory 32, and also provide translated address to address buffers 
42 which drive the translated address onto the controller bus. Control logic 40 then generates control signals to the 
data transceivers 44. address buffers 42 and controller bus to write the display data from the expansion bus data 
signals to controller memory 32 at the translated address driven by address buffers 42. Control logic 40 continues to 
keep processor 34 on hold until the end of a block transfer of display data, i.e. . during burst or back-to-back write cycles 
to the video subsystem. In the event of a burst write cycle or back-to-back write cycles to the video subsystem, advan- 
tageously only the initial cycle has intrusion (i.e., incurs delay cycles), if at all. 

Snooping write cycles to the video subsystem from the expansion bus into controller memory 32 requires synchro- 
nization between the expansion bus and the controller bus since they have different clock signals. This requires multiple 
synchronization points from both buses to guarantee correct states of signalling (i.e., to reduce the possibility of metast- 
ability). It is, therefore, advantageous to determine the earliest point at which a valid write cycle begins and the earliest 
point at which that write cycle, or series of write cycles, ends. It is therefore necessary to determine the earliest point 
at which a valid cycle is not a write cycle in order to negate HOLD, thus returning ownership of the controller bus back 
to the processor 34. This enables processor 34 to perform necessary functions such as processing the playback se- 
quences. Additionally, it is advantageous to determine when a valid write cycle begins in order to, if necessary, drive 
EXRDY low and thereby insert delay cycles. 

Expansion bus clock signal, BCLK, is not particularly useful in determining the beginning and ending of a write 
cycle because it is not guaranteed to be synchronous to either, i.e., the falling edge of STARTS or the rising edge of 
CMDS. For a detailed description of the timing specifications of an EISA bus, reference is made to EISA Specification 
Revision 3.12, which is hereby incorporated by reference. 

The expansion bus Write/Read signal (W_R), indicating a write cycle, is not valid as early as the expansion bus 
address signals (LA). According to EISA bus specifications, W_R cannot be validated until the rising edge of BCLK as 
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STARTS is negating. Control logic 40 must be able to determine if a write cycle is occurring so that it does not respond 
to read cycles but instead allows the video subsystem to respond to read cycles. 

EISA expansion bus signals STARTS and CMDS are not guaranteed to occur in sequence to each other as to the 
negation of STARTS and the assertion of CMDS. That is. the two signals may overlap or gap. Consequently, in order 
to use the falling edge of STARTS to denote the beginning of a cycle and the rising edge of CMDS to denote the end 
of a cycle, an equation wishing to denote the full cycle from start to finish must have some input to cover the potential 
gap between the negation of STARTS and the assertion of CMDS. 

It was determined by the present inventors that in most bus interface implementations using, e.g.. bus interface 
unit 18 as an EISA bus bridge, W_R is valid as BCLK is low and STARTS is asserted low. This information is helpful 
in determining the beginning and end of a valid write cycle. In particular the present invention employs a transparent 
latch control signal. N_START, having the equation; 

N_START = ! BCLK * ! START# + N^START * CMDS: 

Thus. N_START is asserted when BCLK is low and STARTS is asserted low, and stays asserted until CMD# goes 
asserted low to cover the previously discussed START# and CMD# gap. 

An additional signal EARLY_DECODE, is defined which is true when the EISA expansion bus address signals 
are in the video address ranges. 

Combining EARLYJDECODE, W_R, CMD# and N_START a valid write cycle ; is defined as: 

VALID.CYCLE = N_START * EARLYJDECODE * W_R + VALID_CYCLE * ! CMD#: 

Using VALI D_C YCLE, EXRDY is asserted upon VALID_CYCLE being asserted and the processor 34 not yet having 
asserted HLDA. EXRDY is then held asserted until after the next falling edge of BCLK in which HLDA has been granted. 

Thus, control logic 40 advantageously uses N_START to meet the EISA timing requirements with respect to EXRDY 
and thus in typical situations to cause no intrusion, i.e., no introduction of delay cycles, on operations to the video 
subsystem. Control logic 40 also uses N_START to perform synchronization between the EISA expansion bus and the 
controller bus since the two buses have different clock signals. By using N_START (i.e., the term with BCLK being 
low), the control logic 40 advantageously enjoys at least a 60 nanosecond advantage in synchronization time over 
using the rising edge of STARTS (which occurs at least 60 nanoseconds later, i.e., synchronous with the rising edge 
of BCLK) to determine a valid write cycle. 

Referring now to Fig. 10, a timing diagram illustrates the relationship of the EISA expansion bus signals BCLK, 
STARTS, CMDS, LA, W_R to the EARLY.DECODE, HOLD, N_START, VALI D_C YCLE, and EXRDY signals. Fig. 10 
depicts a video write cycle in which processor 34 does not grant HLDA sufficiently early enough and the control logic 
40 must drive EXRDY low to inset delay cycles followed by a second video write cycle. The first and second video 
write cycles constitute back-to-back video write cycles. According to the present invention, the second video write cycle 
advantageously does not incur a delay cycle even though the first write cycle did incur a delay cycle. The edges of 
BCLK are numbered consecutively one through fourteen for clarity in the discussion of Fig. 1 0. HLDA signal shown in 
Fig. 10 is a version of the HLDA signal from processor 34 which has been synchronized to the EISA expansion bus 
clock BCLK. 

EISA bus interface 18, on behalf of CPU 12 wishing to write to the video subsystem, generates an address in the 
video address ranges on the LA signals near BCLK falling edge two. The control logic 40 responsively asserts the 
EARLYJDECODE signal. Shortly thereafter, the control logic 40 asserts HOLD to the processor 34. The HOLD signal 
is asserted when the EARLY_DECODE signal becomes asserted and remains asserted as long as the VALID_CYCLE 
signal remains asserted. By keeping HOLD asserted through VALlD_CYCLE, the control logic 40 keeps ownership of 
the controller bus until the write of the video data to the controller memory 32 completes. Additionally, the HOLD signal 
is asserted as long as EARLY_DECODE is asserted and the defeat timer has not expired (as discussed below). The 
HOLD signal is synchronized with processor 34 clock. Near BCLK rising edge three, bus interface 18 asserts STARTS 
(which is active low) to begin the address phase of the cycle. The bus interface 18 asserts the W_R signal to signify 
a write cycle. 

In response to BCLK falling edge four, the control logic 40 asserts NLSTART since BCLK is low and STARTS is 
asserted low. N_ START remains asserted until the assertion of CMDS low near BCLK rising edge five. N_START being 
active signifies that W_R is valid and since W_R indicates a write cycle and EARLY_DECODE indicates an address 
in the video address ranges, the control logic 40 correspondingly asserts VALI D_C YCLE. In response to VALI D_C YCLE 
being asserted after BCLK falling edge four, the control logic 40 drives EXRDY low since HLDA has not been granted 
(in this example). In this example, HLDA is granted near BLCK rising edge five. The control logic 40 continues to drive 
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EXRDY low until after the next falling edge of BCLK in which HLDA is granted, i e. BCLK falling edge six since EXRDY 
is sampled by bus interface unit 18 on the falling edge of BCLK while CMDS is asserted low. 

Bus interface unit 18 asserts CMDS low and deasserts STARTS high after BCLK rising edge five to begin the data 
phase of the write cycle. As previously noted, the rising edge of STARTS and the falling edge of CMD# here may either 
s gap or overlap according to the EISA expansion bus specification. As previously described. N_START advantageously 
covers the gap so that VALID_CYCLE may denote a valid video write cycle from start to finish. 

In response to EXRDY being driven low during the falling edge of BLCK during CMD# asserted low. i.e. : BCLK 
falling edge six. bus interface unit 13 waits an extra BCLK cycle, i.e.. inserts a delay cycle (or wait state) ; by delaying 
the deassertion of CMD# high for an extra clock cycle near BCLK rising edge nine. CMDS deasserting high denotes 
10 the end of the write cycle. 

Since the address on the LA signals remains in the video range for the second write cycle, control logic 40 continues 
to assert EARLY_DECODE and correspondingly to assert HOLD thus retaining ownership of the controller bus as 
signified by HLDA being asserted through the end of the second write cycle. 

After BCLK rising edge nine, bus interface unit 18 (using EISA bridging) asserts STARTS to signify the beginning 
'5 of the address phase of the second video write cycle. The second write cycle is similar to the first video write cycle 
except that since the control logic already has ownership of the controller bus EXRDY is not negated low during the 
second write cycle. Therefore, bus interface unit 18 deasserts CMD# high near BLCK rising edge thirteen (i.e.. a full 
clock cycle earlier than in the first write cycle) to end the data phase of the second write cycle. 

The second video write cycle is also representative of a non-back-to-back video write cycle in which HLDA was 
20 granted sufficiently early such that control logic 40 did not have to drive EXRDY low to insert delay cycles. 

In one embodiment of the present invention, server controller 26 further comprises a controller video subsystem 
(not shown) similar to the video subsystem of server 10 comprising video controller 20 and video memory 22. The 
controller video subsystem may be selectively disabled by system configuration software. The controller video sub- 
system is an ISA device. If the controller video subsystem is enabled, server controller 26 negates the ISA bus signal 
25 CHRDY rather than the EISA expansion bus EXRDY signal. 

A purpose of the controller video subsystem is to cause writes of video data to appear on the expansion bus in 
the event that the VGA controller on server 10 is a PCI VGA controller. Otherwise, the PCI VGA controller would decode 
and respond to video writes thus causing the bus interface unit 1 8 to not forward the video write to the EISA expansion 
bus. As a result, there would be no video write cycles on the EISA expansion bus or the server controller 26 to snoop. 
30 Thus, when a PCI VGA controller resides in the system, the user must enable the controller video subsystem on the 
server controller 26 and disable the PCI VGA controller in order to enable video write cycle snooping and playback 
sequence capturing. 

It is common for implementations of bus interface unit 18 (i.e., EISA bus bridge) to drive an address on the expan- 
sion bus address signals to, at the end of a valid cycle, latch and drive that address on the expansion bus (i.e., EISA 

35 bus) during an idle cycle occurring after the valid cycle, so the address signals do not float. This condition would cause 
control logic 40 to assert the EARLY_DECODE signal and consequently to assert HOLD to the processor 34 continu- 
ously for relatively large amounts of time. As a result processor 34 would be needlessly starved. One solution to this 
problem would be to negate HOLD at the end of a cycle on the rising edge of CMDS, However the result would be 
that the control logic 40 would have to re-arbitrate for the controller bus and re-synchronize between the E! SA expansion 

40 bus and controller bus for each write cycle of a block of back-to-back write cycles by negating EXRDY thus introducing 
delays. 

The present invention employs a defeat timer in order to solve the problem described above. Control logic 40 
comprises a counter which counts a certain number of BCLKs after a cycle if the EISA expansion bus address signals 
still have an address in the video address ranges. When the counter reaches terminal count without a new assertion 
•*5 of STARTS, the control logic 40 negates HOLD and does not assert HOLD until the next STARTS assertion with the 
control logic 40 decoding an address in the video address ranges. 

Thus, by employing the defeat timer control logic 40 advantageously asserts HOLD earlier than would otherwise 
be possible if the control logic 40 waited until the assertion of STARTS to assert HOLD and is thus more likely to not 
introduce delay cycles to the server 10 during video data writes to the video subsystem. The defeat timer further 
50 advantageously enables control logic 40 to keep HOLD asserted during a block of back-to-back valid video write cycles, 
• thus potentially avoiding introducing delay cycles to server 10 during video data writes to the video subsystem. 

Remote terminal 28 establishes a communications connection with server controller 26 via communication unit 
36. The connection between the remote terminal 28 and server controller 26 is commonly referred to as an out-of-band 
connection, or asynchronous connection. An out-of-band connection refers to a network connection that is established 
55 through a phone line or direct serial connection, rather than through a standard network medium such as a local area 
network Ethernet connection. By providing an out-of-band connection, server controller 26 can establish communica- 
tion with the remote terminal 28 both when server 10 is functioning normally or when a failure occurs, such as an 
operating system crash or a failure on the local area network to which server 10 is connected. 
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In a first mode, remote terminal 28 establishes connection with the server controller 26 using the ANSI terminal 
emulation protocol referred to henceforth as the text protocol. In a second mode, remote terminal 28 establishes a 
point-to-point-protocol (PPP) connection with server controller 26. PPP is described in numerous Request For Com- 
ments (RFC) of the Internet Engineering Task Force {"IETF") whose Uniform Resource Locator ("URL") is http://www. 
ietf.cnri.reston.va. us/home. html. In particular RFC 1661 ; 1662 and 1663 are pertinent to the present invention and are 
hereby incorporated by reference. When the remote terminal 28 dials in to the server controller 26. server controller 
26 software executing on the processor 34 of the server controller 26 advantageously automatically determines which 
of the two data link layer protocols the remote terminal 28 is using. 

In the first mode, a portion of server controller 26 software, referred to as the server controller console application, 
communicates with remote terminal 28 using the text protocol. The server controller console application enables remote 
terminal 28 to access various features of the server controller 26 such as viewing playback sequences. The server 
controller console application additionally allows the system administrator to perform remote resets, manage alert and 
login information, remotely access the console, view event logs, error logs and status logs of server 1 0. Referring again 
to Figs. 2a-2c. three menu screens of the server controller console application are shown. Typically, remote terminal 
28 is a computer executing a popular ANSI terminal emulation software application available from various venders, 
such as the well known products SYMANTEC pcANYWHERE or DATASTORM TECHNOLOGY ProComm, to com- 
municate with server controller 26. 

In the second mode, remote terminal 28 establishes a TCP/IP link with server controller 26 over the PPP connection 
similar to that of a local area network (LAN). Typically, remote terminal 28 executes the COMPAQ Insight Manager 
(CIM) to communicate with the server controller 26 over the TCP/IP connection. Server controller 26 communicates 
with the CIM in two manners. First, server controller 26 communicates with the CIM via a TELNET connection to 
execute the server controller console application just as in the first mode using the text protocol. 

Second, server controller 26 sends/receives SNMP packets to/from the CIM for the purposes of managing the 
server 10. For example, server 10 may detect a failure or other event on server 10 and send an SNMP trap packet 
through server controller 26 to the CIM executing on the remote terminal 28 to notify the system administrator of the 
event just as it would if the CIM were executing on a client on the LAN to which server 10 is connected. Additionally, 
in the event of a server 10 failure, server controller 26 may detect the failure and autonomously send an SNMP trap 
packet to the CIM. In this second mode, i.e., over the PPP connection, server controller 26 may simultaneously com- 
municate with the remote terminal 28 via the server controller console application and SNMP packets. 

Another example of server 10 management via CIM is the remote terminal 28 sending a "get request" SNMP 
packet to the server 1 0 via server controller 26 to request management information about the server, such as the health 
of one of the server's subsystems. Server controller 26 forwards the SNMP packet to the operating system. The op- 
erating system gathers the requested information and sends a "get response" packet to the server controller 26. The 
server controller 26 in turn forwards the packet to the CIM. 

The WINDOWS NT Remote Access Services (RAS) can establish PPP connections to provide communication 
between two computers connected by a null-modem. The NT RAS employs a proprietary method of establishing this 
PPP connection. The method, referred to herein as the "pre-PPP protocol", is to exchange a pair of strings between 
the two computers. The first computer, wishing to establish the connection, sends the string "CLIENT" to the second 
computer. Next, the second computer, after receiving the "CLIENT" string, sends the string "CLIENTSERVER" to the 
first computer. Once this exchange of the two strings has occurred, the two computers proceed to exchange the nec- 
essary character packets to establish the PPP connection. In standard PPP connections this initial exchange of the 
two strings is not required. Server controller 26 is capable of establishing a PPP connection with both the NT RAS over 
a null-modem as well as remote terminal 28 using the standard PPP protocol. 

Referring now to Fig. 11, a flowchart is presented which illustrates how server controller 26 detects which com- 
munication protocol is sent from remote terminal 28. Prior to remote terminal 28 establishing a connection, server 
controller 26 software resets three state machines within the server controller 26 software in step 1 30. A state machine 
exists for each of the valid protocols: the text protocol, the PPP protocol, and the pre-PPP protocol. 

During times when server controller 26 waits for an interrupt from communication unit 36, playback sequences 
can be processed over by processor 34. When a carrier signal is received upon server controller 26, software within 
controller 26 resets the state machines in step 134 and sets a timer in step 136. In one embodiment, the timer is set 
to expire in 30 seconds. The server controller 26 software determines if the timer has expired in step 138. If the timer 
has expired, the server controller 26 software declares the protocol to be the text protocol by communicating to an 
upper level task in the server controller 26 software that the protocol is the text protocol in step 140. 

Prior to receiving a character or signal from remote terminal 28, software within server controller 26 can process 
the video screen changes. Once the interrupt occurs indicative of a character or signal present, server controller 26 
software determines if a "no carrier" signal was sent by the communication unit 36 to indicate a loss of carrier from the 
remote terminal 28 in step 142. If the carrier has been lost, the server controller 26 software clears the timer in step 
144 and returns to step 130. 
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If a "no carrier" signal was not received in step 142. the server controller 26 software determines if a character 
was received in step 146. If not. the server controller 26 software returns to step 138 to wait for either the timer to 
expire or an interrupt to be received indicating that a signal or character has arrived. 

If a character was received in step 1 46. the server controller 26 software passes the character to each of the three 
5 protocol state machines in step 1 48. If none of the state machines detect a valid protocol in step 1 50 the server controller 
26 software returns to step 1 38. If one of the state machines detects a valid protocol in step 150. the server controller 
26 software clears the timer in step 152 and then declares to the upper level task which of the three protocols was 
detected in step 154. 

The processor 34 is configured to receive interrupts from various sources, such as the communication unit 36 as 
to mentioned in the description of Fig. 1 0 above. The processor 34 comprises an interrupt descriptor table, wherein each 
entry in the table references an interrupt service routine associated with an interrupt source. When one of the interrupt 
sources generates an interrupt, processor 34 begins executing the interrupt service routine referenced by the entry in 
the interrupt descriptor table corresponding to the interrupt source. The interrupt service routines are part of the server 
controller 26 software and execute on the processor 34. Communication unit 36 is configured to interrupt processor 
iS 34 upon reception of a character or signal, such a "carrier" or "no carrier", from the remote terminal 28. The interrupt 
service routines communicate with other software tasks executing on the processor 34 to facilitate communications 
with the remote terminal 23. 

Initially, i.e., prior to the remote terminal 28 establishing a connection with the server controller 26. the interrupt 
descriptor table entry associated with the communication unit 36 is populated with a reference to a protocol detection 
20 interrupt service routine. The protocol detection interrupt service routine is the portion of the server controller 26 soft- 
ware which comprises the three protocol state machines. The protocol detection interrupt service routine is also the 
portion of server controller 26 software which receives an incoming character from communication unit 36. Each char- 
acter received by the protocol detection interrupt service routine acts as the input to the three protocol state machines. 
Once the upper level task has been notified that a valid protocol has been detected, either in step 1 40 or step 1 54, 
25 the upper level task populates the interrupt descriptor table entry associated with the communication unit 36 with a 
reference to an interrupt service routine specific to the particular protocol detected. The PPP and pre-PPP protocols 
have the same interrupt service routine. 

Appendix A (see below) contains an assembly language source code listing of portions of the PPP interrupt service 
routine. The code portions illustrate how the interrupt service routine receives and processes incoming characters to 
oo validate and/or form a valid and whole PPP packet. Once a PPP packet has been formed, the interrupt service routine 
notifies an upper level task of server controller 26 software regarding the presence of that packet. 

Referring now to Fig. 12, a state diagram illustrating the text protocol state machine is shown. When the text 
protocol state machine detects three consecutive ASCII "return" characters (0x20), it indicates that a valid text protocol 
has been detected from the remote terminal 28. In the TEXTJNIT state 156, if the state machine receives a carriage 
35 return character, the state machine transitions to the TEXTjONE state 157. Otherwise the state machine remains in 
the TEXTJNIT state 156. In the TEXT_ONE state 157, if the state machine receives a carriage return character, the 
state machine transitions to the TEXT_TWO state 158. Otherwise the state machine returns to the TEXTJNIT state 
1 56. In the TEXT_TWO state 1 58, if the state machine receives a carriage return character, the state machine transitions 
to the TEXTJDETECTED state 159. Otherwise the state machine returns to the TEXT INIT state 156. When the state 
-*o machine reaches the TEXT DETECTED state 159, it notifies an upper level task in the server controller 26 software 
that a valid text protocol has been detected. 

Referring now to Fig. 1 3, a state diagram illustrating the pre-PPP state machine is shown. When the pre-PPP state 
machine detects the string "CLIENT", it indicates that a valid pre-PPP protocol has been detected from the remote 
terminal 28 and correspondingly transmits the string "CLIENTSERVER" to the remote terminal 28. In the CLIENTJNIT 
4 5 state 162, if the state machine receives a C, the state machine transitions to the CLIENT C state 163. Otherwise the 
state machine remains in the CLIENT INIT state 162. In the CLIENT C state 163, if the state machine receives a *L\ 
the state machine transitions to the CLIENT L state 164. This progression is maintained for each of the subsequent 
states 164, 165 and 166 to indicate possible receipt of CLIENT string. If the string is not fully received, then a transition 
occurs back to CLIENTJNIT state 162. Upon receiving the entire string, the state machine transitions to 
50 CLIENTJDETECTED state 168 and notifies an upper level task in the server controller 26 software that a valid pre- 
PPP protocol has been detected. 

The following illustrates the format of the character sequence forming a valid PPP packet: 

SYNCH ADDRESS CONTROL PROTOCOL ... data ... CRC low CRC high SYNCH 
The SYNCH character is designated by a hexadecimal value 0x7E t the ADDRESS character is designated by a 
55 ' hexadecimal value OxFR and the CONTROL character is designated by a hexadecimal value 0x03. The ADDRESS 
and CONTROL character are optional, but if one is present both characters must be present. The PROTOCOL character 
(s) is one or two bytes depending upon the least significant bit (LSB) of the first byte. If the first byte has LSB set (i.e., 
1 ) t then the PROTOCOL character consists of only one compressed protocol byte. If the first byte has the LSB clear 
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(i.e.. 0). then the PROTOCOL characters consist of two uncompressed protocol bytes, the first byte being the low byte 
and the second byte being the high byte. The "data" bytes are the payload of the packet. The CRC, 0W and CRC hjgh 
characters comprise low and high bytes, respectively, of a cyclic redundancy check (CRC) on the data bytes. 

Referring now to Fig. 1 4. a state diagram illustrating the PPP state machine is shown. When the PPP state machine 
5 detects a valid PPP packet, it indicates that a valid PPP protocol has been detected from the remote terminal 28. In 
the PPPJNIT state 170. if the state machine receives a SYNCH character, the state machine transitions to the 
PPP_SYNCH state 172. Otherwise the state machine remains in the PPPJNIT state 170. In the PPP_SYNCH state 
1 72 ; tf the state machine receives an ADDRESS character, the state machine transitions to the PPP_ADDRESS state 
174. Otherwise the state machine transitions to the PPP_CONTROL state 176. In the PPP_ADDRESS state 174. if 
to the state machine receives a CONTROL character, the state machine transitions to the PPP_CONTROL state 176. 
Or, if the state machine receives a SYNCH character, the state machine transitions to the PPP_S YNCH state 172. 
Otherwise the state machine transitions to the PPPJNIT state 170. In the PPP_CONTROL state 176, if the state 
machine receives a SYNCH character the state machine transitions to the PPPJ3YNCH state 172. Otherwise, if the 
LSB of the character is clear the state machine transitions to the PPP_NOT_COMPRESSED state 178 treating the 
*s character as the low byte of two non-compressed protocol bytes and if the LSB of the character is set the state machine 
transitions to the PPP_COMPRESSED state 1 80 treating the character as the single compressed protocol byte. In the 
PPPJMOT_COMPRESSED state 178, if the state machine receives a SYNC character, the state machine transitions 
to the PPP.S YNCH 1 72 state. Otherwise, the state machine transitions to the PPP_COMPRESSED state 1 80 treating 
the character as the high byte of two non -compressed protocol bytes. In the PPP_COMPRESSED state 180, if the 
20 state machine receives a SYNCH character, the state machine transitions to the PPP_DETECTED state 182. Other- 
wise, the state machine remains in the PPP_COMPRESSED state 1 80 and treats the character as a data or CRC byte. 
When the state machine reaches the PPP_DETECTED state 1 82, it notifies an upper level task in the server controller 
26 software that a valid PPP protocol has been detected. 

Server controller 26 provides an optional dial-back security feature to prevent unauthorized users from tampering 
25 with the server 10 via server controller 26. Using the server controller 26 console application software, the system 
administrator configures a list of user profiles each containing a username. password and phone number. When a user 
dials in, the server controller 26 receives a username and password from the user, verifies the username and password 
from the list of user profiles and then disconnects. If the username and password are verified in the list of user profiles, 
the server controller 26 then dials up the associated phone number in the list of user profiles. For an authorized user, 
30 the remote access proceeds as usual. If an intruder had obtained a valid username and password, the intruder will 
nevertheless lose the connection to the server 10 since the intruder will not be dialled back. 

Server controller 26 advantageously dials back the authorized user with the same communications protocol used 
when the user dialled in. For example, if the user connected via a null-modem from a WINDOWS NT machine using 
the pre-PPP protocol, the server controller 26 will dial back the NT machine using the pre-PPP protocol. This is ad- 
35 vantageous since it is likely that the remote terminal will expect to communicate with the server controller 26 using the 
same protocol with which it dialled in. 

Referring now to Fig. 15, various components of server controller 26 are shown arranged upon a PCB 200. PCB 
200 is segregated into a plurality of planes or portions. A first portion 202 accommodates an expansion bus interface 
unit 204 as well as detection logic 30. A second portion 206 accommodates processor 30 and controller memory 32, 
■to as well as a secondary power supply (i.e., battery) denoted as reference numeral 208. A third portion 210 accommo- 
dates communication unit (i.e., modem) 36. Portions 202, 206 and 210 are segregated from each other by a pair of 
decoupling units denoted as first decoupling unit 212 and second decoupling unit 214. 

Power to PCB 200 is normally applied via edge connectors 216 from the expansion bus to which PCB 200 can be 
connected. One pin of edge connector 216 is reserved for primary power VDD routed to first, second and third portions 
45 202, 206 and 210, respectively. Display data is snooped from the expansion bus and is forwarded over possibly several 
pins of edge connector 216 to detection logic 30 via interface unit 204. Upon losing VDD during, for example, server 
power down, decoupling unit 212 serves two functions. First, power conductors within first portion 202 are decoupled 
from power conductors within second portion 206. More specifically, the VDD conductor within first portion 202 is 
decoupled via decoupling unit 212 from the power conductor or conductors within second portions 206. Second, signal 
50 conductors within first portion 202 are decoupled from signal conductors within second portion 206. As the signal 
conductors are decoupled, the signal conductors are tri-stated. 

Similar to the first decoupling unit 212, second decoupling unit 21 4 also decouples the power and signal conductors. 
If VDD ceases from the expansion bus and if communication unit 36 does not detect communication from remote 
terminal 28, then second decoupling unit 21 4 performs its decoupling operation. If, however, VDD is present or if remote 
55 ' terminal 28 is sending communication protocol, then second decoupling unit 214 effectuates coupling between second 
and third portions 208 and 210, respectively. 

Decoupling units 212 and 214 preferably comprise quick switches upon the power conductors and bi-directional 
transceiver with buffer/driver capability between signal conductors. The quick switches are obtainable from various 
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vendors, such as National Semiconductor Corp. and Texas Instruments. Inc.. and are formed as packaged arrays of 
JFETs with a common control input (i.e.. output-enable OE input). The bi-directional transceiver are well suited for 
driving high-capacitive loads and operate under high-speed conditions. A suitable bi-directional transceiver can be 
obtained from Integrated Device Technology. Inc. or Texas Instruments. Inc. as fast CMOS transceiver with tri-state 
5 output capability. 

Coupled to one pin of edge connector 216 is a charge conductor 220. Charge conductor 220 is adapted to receive 
a voltage supplied by the expansion bus defined to exceed VDD. According to one embodiment, the desired voltage 
upon charge conductor 220 is 1 2 volts, wherein VDD equals 5 volts. Voltage supplied by charge conductor 220 serves 
not only to charge battery 208. but also to enable switching of switching regulator 222. If. for example, charge within 
JO charge conductor 220 goes below a threshold value, then switching regulator 222 activates coupling of battery 208 to 
second portion 206. and possibly third portion 210. Conversely, if charge on charge conductor 220 exceeds the thresh- 
old value, then output from battery 208 (i.e., VDDB) is not coupled to second portion 206 and third portion 210. Instead, 
in the latter instance, VDD is present thereto. A diode 224 is used to prevent discharge of battery 208 during times 
when charge upon conductor 220 is terminated. 
'5 A ring indicator 226 is coupled on the same power plane as second portion 206. Specifically, ring indicator receives 

VDDB upon conductor 228 during times when VDD is not present, or receives VDD if VDD is present. Accordingly, 
ring indicator 226 maintains power either from the primary or the secondary sources to detect an incoming analog ring 
ARNG signal. Upon receiving ARNG, ring indicator 226 forwards the ensuing communication protocol to communication 
unit 36 via the digital ring DRNG signal. By always maintaining power to ring indicator 226, detection of an incoming 
20 ring is always possible regardless of VDD status. 

Fig. 16 illustrates a comparator 230 used in determining if VDD becomes less than VDDB by a threshold amount. 
If VDD should happen to drop beyond the acceptable threshold, then comparator 230 produces a VDDOFF signal. 
The VDDOFF signal is presented on the output enable OE pin of decoupling of first decoupling unit 212. Comparator 
230 thereby effectuates decoupling of signal conductors and power conductors between the first and second portions 
25 202 and 206 if VDD supplied by the expansion bus becomes less than VDDB supplied by battery 208. 

Fig. 17 illustrates operation of digital ring DRNG, and its effect upon decoupling of power and signal conductors 
between second and third portions 206 and 210, respectively. If power to communication unit 36 is initially off, DRNG 
signal to communication unit 36 causes an interrupt to processor 34. As such, processor 34 is informed that a ring 
signal is present at communication unit 36, whereby processor 34 can then acknowledge its interrupt through MDMACT 
30 signal as well as presenting power to the modem via MDMPWR signal. More specifically, MDMPWR signal is fed to 
the output enable OE input of second decoupling unit 214. Upon receiving MDMPWR indicative of an incoming ring, 
second decoupling unit 214 couples the power and signal conductors extending between second portion 206 and third 
portion 210. Essentially, DRNG is gated with a signal indicative of whether communication unit 36 is on or off, the 
output of that gate being an interrupt to processor 34. Whenever processor 34 receives an interrupt, power from VDDB 
35 of processor 34 is supplied to communication unit 36. If power to communication unit 36 is on, then an interrupt is not 
asserted. 

It will be appreciated to those skilled in the art having the benefit of this disclosure that this invention is capable of 
applications with numerous types of computer systems, with numerous types of electrical components, with numerous 
types of PCBs and with numerous types of communications protocols. Furthermore, it is to be understood that the form 
•to of the invention shown and described is to be taken as presently preferred embodiments. \&rious modifications and 
changes may be made without departing from the spirit and scope of the invention as set forth in the claims. It is 
intended that the following claims be interpreted to embrace all such modifications and changes and, accordingly, the 
specification and drawings are to be regarded in an illustrative rather than a restrictive sense. 
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itices for receive state machine 



RS_STATE_1 
R3_STATE_2 
RS STATE_3 

rs~state_4 

RS~STATE_5 
RS_STATE_6 
SYNCH 



equ 1 ; waiting tor first SYNCH 

equ 2 ; waiting for another 3YNCK or ADDR 

equ 3 ; got ADDR; waiting for CONTROL 

equ 4 ; read first PROTOCOL byte 

equ 5 ; read second PROTCCOL byte 

equ 5 ; read data, adjusting CRC and waiting for 



RS STATE 7 


equ 


7 ; waiting to get a packet buffer 


RS~3TATE_E 


SC equ 


80h 




; "or now, 


hardcoded 


nod em 


registers for COM3 (15550) 


TKR 


equ 


03e3h 


; Transmitter Holding Register 


RBR 


equ 


03e3h 


; Receiver Buffer Register 


IER 


equ 


03e9h 


; Interrupt Enable Register 


riR 


equ 


03eah 


; Interrupt Identification Register 


ICR 


equ 


03ebh 


; Line Control Register 


MCR 


equ 


03ech 


; Modem Control Register 


LSR 


equ 


03edh 


; Line Status Register 


ms a 


equ 


03eeh 


; Modem Status Register 



These are some bit positions/masks of some of the registers above. 
They are used to assert/clear certain signals. 



IER XMIT equ 


02h 


* Transmit interrupt enable bit in IER 


LSR CHAR AVAIL 


equ 


Olh 


• Char available bit in LSR 


LSR XMIT~EMPTY 


equ 


20h 


THR empty bit in LSR 


MSR DELTA CD 


equ 


08h 


• Delta CD bit in MSR 


MSR CD 


equ 


30h 


CD bit in MSR 


MCft~RTS 


equ 


02h 


RTS bit in MCR 


MSRJTTS 


equ 


lOh 


CTS bit in MSR 


; These are in 


other 


files , 


but are not necessary to 



understand this file. 
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extrn crcl ojiable : word ; 16-bit CRC lookup table 

extrn ppp_buf f er_get_recv : r.ear ; get a packet buffer 

extrn p?p_buf f er_ret__recv: near ; return a packet buffer 

extrn pcp~q write: near ; inform upper layer of packet reception 



ro*/r_done : 

call 

cr.p 

test 
jp.z 

cmp 

prccess_char : 
xor 
rr.ovzx 



ppp_com3_read 

ai, ?PP_SYNCK_CHAR 
process_synch 

ah, RS_STATE_ESC 
escaped 

al, ?PP_ESCAPE_CKAR 
do_escape 



bl,al 
esi, bl 



; read incoming char into AL 

; is it a SYMCH char ? 

; yes, handle these offline 

; was last char an escape ? 

; yes, prccess offline 

; is current char ESC? 

; yes, take care of it 

; we have received a true char 

; modify "the running 

; CRC value to reflect 
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bx, S 


; the char that jusc 






xor 


bx, ere I 6_tab le [es i * 


2] ; came in 






cmp 


ah, ?.S_3TATI_6 


; read a cr.ar of cat a 


5 








; (mcsc common, state) 






cmp 


ah, RS_STATE_5 


; getting 2nd half of protocol 






* *~ 


rx__state 5 






cmp 


ah, RS_STATE_4 


; getting valid protoccl 


to 






rx_s ta t e__4 








cmp 


ah,RS_3TATE_3 


; waiting for CONTROL 






* *" 


rx^s cats 3 






one 


ah, RS_STA7E_2 


; waiting fcr ADDRESS, CONTROL 


15 




j 2 


rx_state 2 


; or valid protoccl 






cmp 


ah, RS_STATE_1 


; waiting for SYNCK , so 






j - 


rcvr_done 


; threw away this char 






cmp 


ah, RS_5TATE 7 


; wait 'no for a. buf f 


20 




jz 


rx_state 7 








ah, RS_S7ATE 1 


; if we fell through there's a 










; problem. . . 






jmp 


rcvr_done 




25 




state_2 : 










mov 


edi,ppp_com3 rx buffer 


start ; re-initialize these two 










; variables 






mov 


ebx, ?PP_FCS16_INITIALJ/ALUE ; so we always start in 










; a Icr.own state 






xcr 


bi,ai 


/ modify the running 


30 




movzx 


esi, bl 


; CRC value to reflect 






shr 


bx, 8 


; the char that just 






xor 


bx, crclS_cable [esi*2] ; came in 






cmp 


al, ??P AD0RES3 FIELD 


; is it the ADDRESS field ? 






mov 


ah, RS_STATE_4 


; assume r.o 


35 




jns 


rx stace 4 


; good guess 






mov 


ah, RS_STATE_3 


; cops , bad guess 






jmp 


rcvr_done 


; go get C3NTF.OL field 




rx_scace 3: 










cmp 


■ ai,PP? CONTROL FIELD 


/ did we get CONTROL ? 


40 




mov 


ah, RS_3TATE_4 


; assume yes 






jz 


revr^done 


; good guess 






no? 


ah, RS_3TATE_1 


; wrong, since there is no 






jmp 


rev redone 


; protocol FF ( reset state 










; machine 


45 


rx s 


cate_4 : 










movzx 


ax, ai 


; expand into AX 






test 


al, 1 


; compressed protocol ? 






j z 


high_part 


; no 






mov 


word per ppp com3 rx 


^protocol , ax; yes, so store it 


SO 




mov 


ah, RS_STATE_6 


and go to 




jmp 


rev redone 


the next state 




high 


part : 










shl 


ax, S 


; we only got the high 3 bits 






mov 


word ptr ppp_com3_rx_ 


_protocol,ax ; store the 










; temporary result 


55 




mov 


ah, RS_STATE_5 


7 and.go to 






jmp 


rcvr_done 


; the next state 
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w 



rx_state_( 

test 

3 = 
mov 



mcv 
jmp 

cac_prctoc_I : 

jmp 



ai, 1 ; this had batter be sec 

baa_p rorocoi ; bad packet header 

byte ptr pp?_com3_- :<_procccci , a! ; everything's 

; cool, 
; save it 

ah, RS_STATE_5 ; and co to 

rcvr done ; the next state 



ah,RS_STATE_l 
rcvr done 



; reset state machine 
; ar.d get another char 



IS 



rx — stata o : 

szcsb 



jmp 



rcvr done 



; we have a valid data char 

; so store it 

, and fail through (it's a 

; given) 



rx sts: 



20 



25 



30 



call 
tnov 
inc 
or 

U 
mov 
mcv 
jmp 



escaped : 

and 
xor 
jmp 

do_escape : 
or 

jmp 



?pp_buf f er_get_recv 
edi , eax 
eax 

eax, eax 
rcvr_done 

p?p_ccm3 jrxjouf f er_start , edi ; yes, reset the pointer 
ah, R5_STATE_1 ; and gc to state 1 

rcvr_done / waiting for a synch 



; see if we can get a buffer 

; save result in EDI 

; turns -1 Into 0 

; did we get a buffer ? 

; no, stay in this state 



ah, 07fh 

ai, ?PP_ESCAPEJCOR_MASK 
process char ~" 



ah,RS_STATE_ESC 
rcvr done 



clear RS_STATE_ESC flag, 

xform this char, 

then process it normally 

upon receiving an ESC 
we sec the RS_STATE_ESC 
flag ~ 
and drco this char 
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:rocess_synch : 
cmp 

j2 



cmp 

u 

cmp 



ah, RS_STATE_o 
svnch 6 



ah, RS_STATE_2 
rev redone 
ah, RS_STATE_1 
syr.ch_l 



we are inside of a packet 
this- state is the most 
common one encountered 
under normal conditions 
we already got a SYNCH 
so drop this char 
we have been waiting for 
this SYNCH to come along 
to start off a block 



45 



cmp ah,RS_STATE_3 
jz synch~3 



we have already received 
the ADDRESS, so this 
SYNCH makes a short 
packet. discard it 



50 



55 



cmp ah , RS_STATE__4 

jz synch A 



cmp ah, RS_STATE_5 

j z synch 5 



we have air 
the ADDRESS 
CONTROL, bu 
theref c: 
packet 
we have rec 
ADDRESS and 
field and o 
byte of the 
fiel.d. 
this SYNCH 
for a short 



eady received 

and the 
t no protocol . 
dump this 

eived both the 

the CONTROL 
nly the first 
protocol 

therefore makes 
packet, so 
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cmp 



w 



15 



20 



ah, RS_STATE_7 

synch 7 



we wiil discard ic 
Okay, here's the cough one 
so listen up * In order 
to ce: ro s r a t e 7, a 
valid packet came in anc 
we sent the message off 
to pSCS, but when we 
tried to get a MEW packet 
buffer for the .NEXT 
packet, 

there were' none left. The 
fact that a packet was 
just sent out means that 
we DID RECEIVE the SYNCH 
char, and so if we receive 
ANOTHER one it means that 
we have stayed in state 7 
for the duration of an 
entire packet. the upper 
layer needs to be nade 
aware of the fact that 
a bad packet was received 
so that VJ compress ion 
will work correctly. 



25 



pu s hd 
bad_packet : 
pop 
mov 
mov 
cail 
mov 
imo 



631 

ec:<, P?P_ERROR 

edx, ppp_com3_interface 

ppp_q_write 

ah, RS_3TATE_2 

rcvr done 



internal 



state error 



reset everything 



30 



synch_l : 



mov 
jmp 



ah, RS_3TA.TE_2 
rcvr done 



everything's great so 
go to the next state 



35 



synch_3 
synch_4 
synch 5 



mov 



ah, RS_STATE_2 
rcvr done 



inc shcrt_packat_count 
Drop z his packet, and 
then check for more chars 



synch 7: 



40 



mov 

mov 

mov 

cail 

mov 

jmp 



ecx, P?P_ERROR 

edx, cpp_com3_interf ace 

esi , 4 

ppp_q_write 
ah, RS - STATE_7 
rx state 7 



45 



stay in state 7 and try 
to get another buffer 



synch_6 : 



50 



sub 
cmp 



eci, ppp jcom3_rx_buf fer_start ; get length of packet 



edi , 2 



it needs to at least have 
2 bytes if we are using 
CRC 16 ECS 



pushd 

jb 

add 



bad_packst 
esp, 4 



; short packet error 

; send an error and reset 



55 



cmp 
pushd 



bx,=P? rcsi6_G0OD VALUE ; does the CRC match 7 
2 " ; CRC error 
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jn' bad_packet ; no, so send error and discard 

add esp, 4 

-ub edi,2 ; yes, but don't send CRC as 

; part of packet 

mov ax, word ptr ppp_com3_r:<_protccol ; encode the 

; protocol as the 

shl eax, 16 . upper L6 bits of the 

or edi,eax ; length field 

mov ecx, PPP_PACKET_RECEIVED ; message_type 

mov edx, ppp_com3_interf ace ; interface 

mov esi, ppp_com3_rx_buf fer_start ; message_ptr 

call ?pp_q_write ; This is the line of code that 

; notifies upper layers that the 
; PPP packet was indeed valid. 

or eax, eax ; did it fail ? 

jz drop_packet ; yes, throw away the packet 

call ppp_buf f er_get_recv / no, so get a new packet buffer 

mov edi,eax 

inc eax 

or eax, eax 

mov ah, RS_STATE_7 

j z rcvr_done 

mov ppp_com3_rx_buf f er_start , edi 
drop_packet: ~" 

mov ah, RS_STATE_2 

jmp rcvr done 



Claims 

1. A computer, comprising: 

a host central processing unit (CPU); 

an expansion bus operably coupled between said host CPU and a video controller; and 
a server controller connected to said expansion bus, wherein said server controller comprises a controller 
memory for storing display data forwarded from said host CPU to said video controller during a first time period 
prior to failure of said computer and during a second time period after reset of said computer 

2. The computer as recited in claim 1, wherein said expansion bus comprises an EISA bus. 

3. The computer as recited in claim 1 or claim 2, wherein said video controller is coupled to a video memory such 
that both said video controller and said server controller are responsive to address information within a video 
address range for simultaneously storing said display data in both said video memory and controller memory, 
respectively. 

4. The computer as recited in any of claims 1 to 3, wherein said host CPU is connected to a local CPU bus. 

5. The computer as recited in claim A, further comprising a bus interface unit coupled between said local CPU bus 
and said expansion bus. 

6. The computer as recited in any of claims 1 to 5, wherein said server controller comprises detection logic coupled 
between said expansion bus and said controller memory for monitoring said display data forwarded across said 
expansion bus to said video controller and for thereafter writing said display data to said controller memory. 
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7. The computer as recited in claim 6. wherein said display data is forwarded across said expansion bus during times 
when said host CPU writes said display data to said video controller. 

8. The computer as recited in any of claims 1 to 7, wherein said controller memory comprises: 

5 

a local frame buffer for storing a current display screen of said display data forwarded to said video controller; 
and 

a temporary snapshot buffer coupled to receive the current display screen of said display data forwarded from 
said local frame buffer; 

10 a snapshot buffer coupled to receive a previous display screen of said display data forwarded from said local 

frame buffer: and 

comparison logic coupled between said temporary snapshot buffer and said snapshot buffer for determining 
a change between said previous display screen and said current display screen of said display data. 

'5 9. The computer as recited in claim 8, wherein said controller memory further comprises a current reset sequence 
buffer for storing said change during said second time period. 

10. The computer as recited in claim 8, wherein said controller memory further comprises a current sequence buffer 
operably coupled to a current start buffer, and wherein said change is forwarded to said current sequence buffer 

20 and any overflow therefrom is forwarded to said current start buffer during said first time period. 

11. A server controller comprising: 

detection logic adapted for coupling to a server to determine the presence of display data forwarded from the 
25 server: 

a controller memory coupled to said detection logic, wherein said controller memory comprises a local frame 
buffer and a current reset sequence buffer: and 

said local frame buffer is configured to store a current display screen of said display data, and said current 
reset sequence buffer is configured to store a change between the current display screen of said display data 
30 and a previous display screen of said display data during a time period after which said server receives a first 

reset. 

12. The server controller as recited in claim 11, wherein said change between the current display screen of said display 
data and the previous display screen of said display data is represented as a packet of digital data. 

35 

1 3. The server controller as recited in claim 1 2, wherein said packet of digital data comprises fewer binary values than 
a set of binary values used in storing either the current display screen or the previous display screen. 

14. The server controller as recited in claim 12, wherein said packet of digital data comprises a byte of data indicative 
*o of a character to be displayed and another byte of data indicative of attributes given to the character to be displayed, 

said attributes are selected from the group comprising colour and intensity. 

1 5. The server controller as recited in claim 1 2, wherein said packets are arranged in series representing a sequence 
of video screen changes which occur after said server receives the first reset. 

45 

16. The server controller as recited in any of claims 11 to 15, wherein said current reset sequence buffer is adapted 
for access by a terminal located remote from said server to display upon said terminal a sequence of video screen 
changes which occur after said server receives the first reset. 

so 17. The server controller as recited in any of claims 11 to 16, further comprising: 

a previous reset sequence buffer configured to store said change between the current display screen of said 
display data and the previous display screen of said display data upon the server receiving a second reset 
prior to the first reset; and 

55 said previous reset sequence buffer is adapted for access by a terminal located remote from said server to 

display upon said terminal a sequence of video screen changes which occur after the server receives said 
second reset, wherein the current reset sequence buffer is adapted for access by said terminal to display upon 
said terminal a sequence of video screen changes which occur after said server receives the first reset. 
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18. A server controller, comprising: 

detection logic adapted for coupling to a server to determine the presence of display data forwarded from the 
server: 

5 a controller memory coupled to said detection logic, wherein said controller memory comprises a local frame 

buffer and a current sequence buffer: and 

said local frame buffer is configured to store a current display screen of said display data, and said current 
sequence buffer is configured to store a change between the current display screen of said display data and 
a previous display screen of said display data during a time period before which said server fails. 

w 

19. The server controller as recited in claim 1 8 : wherein said change between the current display screen of said digital 
data and the previous display screen of said digital data is represented as a packet of digital data. 

20. The server controller as recited in claim 1 9, wherein said packet of digital data comprises fewer binary values than 
1 5 a set of binary values used in storing either the current display screen or the previous display screen. 

21 . The server controller as recited in claim 1 9 : wherein said packet of digital data comprises a byte of data indicative 
of a character to be displayed and another byte of data indicative of attributes given to the character to be displayed, 
said attributes are selected from the group comprising colour and intensity. 

20 

22. The server controller as recited in claim 1 9, wherein said packets are arranged in series representing a sequence 
of video screen changes which occur before said server fails. 

23. The server controller as recited in any of claims 19 to 22, wherein said current sequence buffer is adapted for 
25 access by a terminal located remote from said server to display upon said terminal a sequence of video screen 

changes which occur before said server fails. 

24. A method for accessing a sequence of display screens forwarded from a server to a video controller comprising: 

30 loading into a local frame buffer a current display screen of display data forwarded from the server to the video 

controller; 

comparing the current display screen of display data to a previous display screen of display data previously 
loaded into said local frame buffer to produce a screen change packet; 

repeating the steps of loading and comparing for a sequence of display screens compiled as a plurality of 
35 screen change packets which occur during a first time period immediately prior to failure of said server and 

during a second time period immediately after reset of said server; and 

assessing said plurality of screen change packets by a terminal located remote from said server to display 
upon the terminal said sequence of display screens. 

•to 25. The method as recited in claim 24, wherein said loading comprises snooping an expansion bus for addresses 
within a specific address range sent over the expansion bus from the server. 

26. The method as recited in claim 24, wherein said accessing comprises remote dialling from the terminal into a 
modem coupled to a buffer configured to store said plurality of screen change packets. 

45 
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FIG.1 



z: 
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FIG.2a 

REMOTE INSIGHT MAIN MENU 

1. ACCESS REMOTE CONSOLE 

2. VIEW EVENT LOG 

3. VIEW STATUS INFORMATION 

4. VIEW SERVER RESET SEQUENCE 

5. VIEW SERVER CRITICAL ERROR LOG 

6. MANAGE LOGIN INFORMATION 

7. MANAGE ALERT INFORMATION 

8. RESET REMOTE SERVER 

9. DISCONNECT 

<TAB>=NEXT <ENTER>=SELECT <F1>=HELP 



FIG.2b 

I : VIEW SERVER RESET SEQUENCE 



1. PREVIOUS RESET SEQUENCE REPLAY 

2. CURRENT RESET SEQUENCE REPLAY 

3. FAILURE SEQUENCE REPLAY 



<TAB>=NEXT <ENTER>=SELECT <ESC>=BACK <F1>=HELP 



FIG.2c 

SERVER RESET SEQUENCE PLAYBACK 

PRESS <SPACE> TO BEGIN THE SEQUENCE REPLAY 
DURING THE REPLAY: 

PRESS <ESC> TO STOP THE PLAYBACK AND RETURN TO THE MENU. 
PRESS <ENTER> TO PAUSE OR RESUME THE PLAYBACK. 
PRESS <1-9> TO INCREASE OR DECREASE TO PLAYBACK SPEED. 
(1=SL0WEST. 9=FASTEST) 



<ESC>=BACK 
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